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ABSTRACT 


This dissertation presents a Holistic Framework for Software Engineering (HFSE) 
that establishes collaborative mechanisms by which existing heterogeneous software 
development tools and models will interoperate. Past research has been conducted with 
the aim of developing or improving individual aspects of software development; 
however, this research focuses on establishing a holistic approach over the entire 
development effort where unrealized synergies and dependencies between all of the tools' 
artifacts can be visualized and leveraged to produce both improvements in process and 
product. 

The HFSE is both a conceptual framework and a software engineering process 
model (with tool support) where the dependencies between software development 
artifacts are identified, quantified, tracked, and deployed throughout all artifacts via 
middleware. Central to the approach is the integration of Quality Function Deployment 
(QFD) into the Relational Hypergraph (RH) Model of Software Evolution. This 
integration allows for the dependencies between artifacts to be automatically tracked 
throughout the hypergraph representation of the development effort, thus assisting the 
software engineer to isolate subgraphs as needed. 
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I. INTRODUCTION 


A, MOTIVATION 

The Department of Defense and the nation beeome more reliant on software every 
day; yet, eonsistently producing high quality software on-time and within budget that 
fully meets customers' requirements is challenging for many reasons. While there have 
been many investigations to address this challenge, "understandability" (or the lack 
thereof) is considered to be a major issue. Exacerbating this issue are the needs for 
holistic and coherent development processes and adequate requirements engineering 
integration. 

1, Software Understandability 

Consider the following charts (see Figure 1) related to total costs during the 
Software Development Lifecycle and the cost impact of maintenance — where 
"maintenance" refers to all activities beyond the initial release. 


SW Life-Cycle Costs (after [LIEN78]) Costs of "Understanding" (after [PARI83]) Type of Maintenance (after [SOMM01]) 



Figure 1 Life-Time Costs of Software Development 


The first pie chart in Figure 1 illustrates that maintenance costs dominate initial 
software development costs by a factor of three. The second chart illustrates that costs 
associated with "understanding" exactly what to maintain account for almost half of the 
maintenance costs (i.e., studying and understanding what to add, correct, or change is 
almost as expensive as actually performing maintenance coding and testing). While data 
supporting the first two charts is somewhat dated, [MEYE97] and [BOEH95] confirm 
that more recent evidence still supports these older observations. Finally, the third pie 

chart illustrates how the maintenance costs are divided; illustrating that “understanding” 
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is required in three different contexts depending on the particular type of maintenance to 
be performed. Together, these charts imply that it is not enough to simply improve 
individual tools and/or the process used to develop software; software engineering 
researchers must take a more holistic view of how software is handled over its entire 
lifecycle and improve how the tools and processes work together over long periods of 
time to overcome the understandability challenge. This holistic view considers the whole 
of the software lifecycle and does not simply focus on a single iteration of the lifecycle, 
or a single process within an iteration, or a single set of software artifacts produced by an 
individual process. Unfortunately, rather than taking such a holistic approach, the lion's 
share of software engineering research has been devoted to meeting this challenge by 
improving specific aspects of the software development process (e.g., requirements 
engineering, reuse, testing), by improving the software development process itself (e.g., 
evolutionary prototyping, spiral development), or by improving individual tools for these 
processes (e.g.. Rational Rose, Requisite®Pro, DOORS). Although "Software 
Evolution" has become a mainstream software engineering subfield, there has still been 
little unifying research that attempts to determine the best way that these tools and 
models should (and could) interact to address the "understandability" problem directly. 

There appear to be two aspects to this problem of understandability. First, the 
engineer must always have an "understanding" of what the customer wants (even years 
after the original requirements were articulated). Second, the engineer needs to have an 
"understanding" of what previous software engineers have done to address the customer's 
requirements. While documentation is good at recording decisions and agreements, it is 
ineffective at recording the detailed knowledge required to understand how a software 
program really works [MCBR02]. There are at least two approaches that could be taken 
to solve the understandability problem. 

a. Produce Tools to Promote Understandability of Customer 
Desires and Legacy Software Development Efforts 

One approach would be to build some tools: a tool that does a better job 
of requirements engineering by continually (over the lifecycle of development) querying 
customers as to what they want and how those desires impact all artifacts of the 
development, and a second tool which could intelligently parse through pertinent current 
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and past software development artifaets reeognizing and extraeting just the information 
the engineer needs at exaetly the time it is needed (and it has to be able to do this with 
any artifaet, produeed by any tool). 

b. Produce a Framework that Promotes Understandability of 
Customer Desires and Legacy Software Development Efforts 

Another approaeh would be to establish a holistie framework where all the 
information is reeorded as it is ereated and the relationship of the artifaet (to all other 
artifaets) is automatieally traeked throughout the lifeeyele. The framework would be 
flexible enough to work with any development tool or model. The relationship of a new 
pieee of information to all others is established on ereation and the software engineer uses 
the dependeneies of the artifaets to extraet relevant information (using engineer defined 
eontexts or views). However, just reeording the information is not enough to justify the 
additional overhead of entering sueh information into a system. As [LEHM69], a pioneer 
in the field of software evolution, stated, "The manager faeed with the daily problems of 
meeting a deadline will always first abandon methodology and systematies." Engineers 
will not use sueh a framework unless it ean help instantiate detailed eonsequenees of 
explieit high-level deeisions and help to propagate eonsequenees of ehanges. 

Of these two approaehes for taekling the "understandability problem," the "tools" 
solution appears to be beyond eurrent teehnologieal eapability; however, the "framework" 
option shows promise and is the foeus of this dissertation researeh. 

2. Holistic Development 

Software engineering researeh is typified by developing or improving individual 
aspeets of software development. Examples inelude researeh into software evolution 
models, requirements engineering, risk and eost estimation, software reuse, prototyping, 
testing, software integration, software maintenanee, re-engineering, performanee 
analysis, domain analysis, arehiteeture design, ete. These individual aspeets of software 
development neeessitate that the software engineer provide any needed interfaee between 
different development models and tools (see Eigure 2). 
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Figure 2 Typical Software Development Process Interaction 


While there has been plenty of researeh into the development of Integrated 
Software Development Environments (ISDEs) [EEHM87], [BROW92, 93], [KADI92a, 
b], [ARCA95] and software development tool suites [RATI98], [KRE1C96], there has 
been little research into holistic models to define how these various threads and processes 
could (and should) most efficiently and effectively interact over the entire lifecycle of the 
software development effort. Currently, there is inadequate long-term communication of 
risk and requirements across disjoint tools and models. 

A proponent of agile software development processes, [MCBR02] notes that 
while there has been a great deal of research effort and money devoted to trying to 
remove the human from the software development process, this effort has met with little 
success. Software engineers can only automate parts of the process; they cannot 
automate processes that require rich interactions between people. Eor instance, the gap 
between requirements specification and design specification cannot be filled with 
automated tools; only skilled developers can bridge such a large and complex gap. 
[MCBR02] states that most parts of the software development process that can be 
automated have been automated; what remains is to make the best use of the tools at 
hand. As engineers automate successive parts of the development process, they are not 
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able to eliminate eomplexity; they are only able to manage it. Thus, there is mueh to be 
gained by improving the way in whieh developers use existing tools, rather than 
eonstantly developing new ones. 

The development of a holistie framework potentially provides seamless 
interoperability between software development proeesses allowing software systems to 
be produeed more effieiently and reliably with high quality. Additionally, the existenee 
of sueh a framework enhanees the diseovery of dependeneies among different aspeets of 
the software engineering proeesses. The hope is that it will enable software engineers to 
diseover proeess improvements. The long-term goal of this researeh is to support all 
aspeets of software engineering; however, the immediate goal presented in this 
dissertation is to demonstrate the theoretieal feasibility of integrating a seleeted subset of 
models and tools using a holistie framework. 

3. Requirements Engineering 

At least one third of software development projeets (ineluding military projects) 
run into trouble for reasons that are directly related to requirements gathering, 
requirements documenting, and requirements management. A Standish Group (1994) 
study (as reported in [LEFFOO]) noted that the three most commonly cited factors that 
caused software projects to be "challenged" were (with some overlap in percentages) as 
follows: 

• Fack of user input: 13% of all projects, 

• Incomplete requirements and specifications: 12% of all projects, and 

• Changing requirements and specifications: 12% of all projects. 

Amplifying this problem is the fact that fixing errors missed during the 
requirements phase can be extremely costly. Depending on how much later the error is 
discovered, the party acquiring a software system may incur costs for re-specification, 
redesign, change orders, recall of defective versions, service costs, documentation, and 
retraining. The Federal Aviation Administration’s (FAA’s) Advanced Automation 
System (AAS) is an example of how significantly costs rise when requirements errors are 
identified and addressed at later stages in a development effort [GAOT98]. The data 
related to requirements management demonstrates the following two things: 
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• Requirements errors are the most likely eategory of error. 

• Requirements errors tend to be the most expensive error to fix. 

A requirements-based methodology used widely in the global produet industry to 
meet these same ehallenges of understandability, quality, safety, and reliability in highly 
eonstrained time/budget development environments is a methodology known as "Quality 
Funetion Deployment" or "QFD". QFD is foeused on meeting three major ehallenges in 
the development of produets: ensuring that the "voiee" of the eustomer is adequately 
transferred to eaeh segment of the development effort, ensuring that there is no loss of 
development information, and ensuring that different segments of the development effort 
are working in eoneert to satisfy the same set of eustomer requirements. As stated by 
one of the pioneers of QFD in the United States [CLAU88], QFD "faeilitates a holistie 
response to eustomer needs." QFD allows engineers to summarize basie data in usable 
form. It allows marketing exeeutives to direetly hear the eustomer's desires. It allows 
general managers to diseover strategie opportunities. QFD eneourages all of the different 
groups in a development effort to work together to understand one another's priorities and 
goals [HAUS88]. 

However, the use of QFD as applied to software development has been very 
limited. In a 1995 survey of thirty-seven major software vendors (eompanies that 
produee and sell software as a major eomponent of their business operations) only 16% 
of them used Software QFD (SQFD) [HAAG96]. There are two reasons eited for this: 

• SQFD has not been rigorously integrated throughout existing software 
development models and tools. 

• Material published to date about SQFD has been highly eoneeptual with 
little pragmatie applieation. Companies that are sueeessfully using SQFD 
are reluetant to offer up their praetieal experienee and the eompetitive 
advantage that the SQFD has afforded them. 

As eited in the survey, all major software vendors pereeived that the 
requirements-gathering tools in their respeetive software development methodologies 
were not adequate. QFD is a methodology that speoifieally targets the problems in 
requirements management by ensuring that the "voiee of the eustomer" is appropriately 
deployed throughout the follow-on phases of the design and is not forgotten or 
misinterpreted immediately after the requirements eapture phase. However, as of now. 
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QFD must be manually integrated into software development proeesses; there are no 
meehanisms for having it automatieally internet with existing software development 
tools. This researeh seeks an improvement to this status quo by ineorporating automated 
QFD meehanisms into a software evolution model. 

4. Coherent Development 

In most software development efforts the requirements engineers ean readily point 
out whieh requirements are the best analyzed and most elearly stated. The software 
arehiteets proudly show off portions of the arehiteeture that employ the best teehnology 
and will be eneapsulated in the most eohesive and least eoupled modules. The 
programmers ean point to the eode that is most elegantly eoded and the testers ean 
exaetly identify the portions of eode that have been most thoroughly tested and likely 
have the fewest defeets. Unfortunately, it is only by aeeident that any of these "best" 
areas of development will eoineide with the partieular funetionality that the eustomer 
thinks provides him the greatest value — "medioere software is the result" [ZULT93]. 
Sueh observations are not new. [LEHM69] in eommenting on how hierarohieal 
management attempts (but fails) to handle this problem states: 

The eonsequenees of this proeedure [hierarohieal projeot management] are 
apparent. Communioations within a group, and more importantly, 
between different groups, tend to be random and a matter of ohanoe. 
Personal relationships between individuals exert a strong influenoe on 
final system struoture, distribution and oontent. Optimisation, if any, is 
looal within eaoh group. Thus the system beoomes an assembly of its 
parts, amorphous, redundant and with random, largely invisible, 
oommunioation. Attempts to debug, improve or enlarge the system 
become very difficult tending to cause its collapse. 

Thus, while the problems of incoherence in software development were recognized as far 
back as 1969, little has changed to correct the problem. 

It has been noted that traditional, non-software product development can also be 
incoherent with respect to the attributes that customers associate with a quality product. 
However, the use of QFD addresses this problem by focusing all of the company's 
development efforts in the same direction [CLAU88]: 

Although much of the initial attention given to QFD in the U.S. focused 
on its formats, QFD's style of organizational behavior is even more 
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important. This style emphasizes multifunetional teams that work to 
aehieve eonsensus about eustomer requirements and produet-expeetation 
requirements. This helps break down segmentation among the various 
eorporate funetions and brings the eolleetive wisdom of the eorporation to 
bear on the produet. The team produees produet speeifieations responsive 
to eustomer needs that will be vigorously worked on by all the funetions. 

This eompares with today's style of eaeh funetion doing its own thing and 
then throwing the result over the wall to the next funetion... There's a 
tendeney for speeialists to stay eloistered within their speeialties. 
Individually, they eontribute tremendous speeialized knowledge, but 
there's some diffleulty in integrating that knowledge so that it provides a 
holistie response to eustomer needs. 

[ZULT92] reinforees this view for software: 

Traditional [software] development is unfoeused with respeet to quality. 

The best analyzed requirements are not the best designed. The best 
designed elements are not the best eoded. The best eode is not the best 
doeumented. It is only by ehanee that the best efforts of one phase reeeive 
the best efforts of a subsequent phase... Ineoherent proeesses are 
ineffleient and expensive ways to satisfy eustomers, often foreing trade¬ 
offs of quality for sehedule or resourees. 

What is needed is a holistie approaeh that allows the software developer to have 
visibility over the more important (as opposed to less important) aspeets of the 
development effort so that they may reeeive appropriate attention and resourees. Thus, 
by sueeessfully integrating QFD into the software development evolution proeess, 
software engineers may later extraet partieular sliees of the development effort that have 
partieular meaning, allowing them to work in a more eoordinated and eoherent manner, 
make better deeisions, and produee better software. 

5. Software Safety 

"Software safety" has beeome a signifieant system issue. Inereasingly, software 
is used in safety-eritieal applieations during whieh if the software fails, there ean be 
injury, loss of life, property damage, or effieaey losses. Managing the safety risk 
assoeiated with the software eontrol of eritieal funetions requires a struetured, diseiplined 
system safety management and engineering approaeh that foeuses on the unique aspeets 
of software in a systems eontext. Holistie approaehes provide the software engineer 
visibility of the dependeneies between safety-related software artifaets. Sueh visibility 
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permits the engineer to confidently modify safety-critical software, knowing that the 
dependencies associated with changes are being tracked. Producing safety-critical 
software is an expensive and time-consuming endeavor. Much of the expense and time is 
due to identifying all "knock-on" effects when modifying safety-critical parts of the 
software. A holistic model can make it possible to identify all of these "knock-on" 
effects in a timely and systematic manner. The model itself can be automated to some 
extent, freeing the software engineer from the mechanistic aspects of injecting quality 
into software systems. 

Many of these safety-critical problems and requirements are the same as those 
faced by NASA. QFD has been used successfully as a methodology that manages safety- 
critical requirements for large complex space systems [DEAN92] by ensuring that safety 
requirements are deployed throughout the follow-on phases of the design. 

6, Solving these Problems with the Holistic Framework For Software 
Engineering (HFSE) 

The following elements are required to deliver any reliable, safe, and quality 
software system of any significant scope [LEFFOO]; 

• A pragmatic process for defining and managing the requirements for 
software; 

• A solid, rigorous, and repeatable methodology for the design and 
development of software; 

• The application of various proven, innovative, techniques for verifying 
and validating that the software is safe and effective; and 

• Extraordinary skills and commitment on the part of both the software 
development and software quality assurance teams. 

This dissertation implements these elements by employing a Holistic Framework 
for Software Engineering (HFSE) that not only lets software engineers work faster , but 
lets them work smarter with greater understanding of customer desires and previous 
development work. The Holistic Framework is established by embedding the relevant 
portions of the Quality Function Deployment methodology into the Relational 
Hypergraph Computer Aided Software Evolution model, then integrating this extended 
evolution model with a Federation Interoperability Object Model created from the tools 
and models used by the development team. While there is no “silver bullet” that will 
solve all software development problems, the HFSE provides an improved requirements- 
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based model upon whieh to develop safe, reliable software, produeed on-time and on- 
budget that fully meets the eustomers' requirements. 

This researeh eonstitutes an initial investigation into the development of the 
HFSE that establishes meehanisms by whieh existing software development tools and 
models ean work together. This dissertation demonstrates that establishing a 
mathematieal framework that allows existing software engineering proeess models (and 
tools supporting those models) to seamlessly interaet is teehnieally feasible. Moreover, 
this dissertation presents the methods and prineiples needed to realize sueh a framework 
and the assoeiated eomputer aids. The longer-term future goals of this line of researeh 
are to aetually improve the effieieney of software development proeesses and to improve 
previously developed software's quality, safety, and reliability by applying the framework 
to speeifie development efforts. 


B, RESEARCH HYPOTHESIS AND METHODOLOGY 

1, Research Hypothesis 

The following is a statement of the Dissertation Hypothesis: 

It is theoretieally feasible to integrate a seleeted set of software 

development tools and/or models through applieation of a Holistie 

Framework for Software Engineering (HFSE), 

Where 

• The HFSE eonsists of an extended Software Evolution model 
(extended with Quality Funetion Deployment (QFD)) integrated 
with a Federation Interoperability Objeet Model (FIOM) of the 
subordinate software development tools/models. 

• The integrated tool/model set provides additional interoperability 
(i.e. additional data exehange and joint task exeeution) beyond that 
interoperability available prior to the applieation of the HFSE to 
the software development tool set. 

2, Research Methodology 

This researeh was eompleted by exeeuting five major tasks: developing a software 
development tool ontology, integrating QFD into the Relational Hypergraph model of 
software evolution, ereating an objeet model of software development tools and 
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integrating that model with the evolution model, prototyping the HFSE by extending the 
Computer-Aided Software Evolution System (CASES), and applying the HESE to a set 
of software development tools to provide eonfirming evidenee for the research 
hypothesis. 

a. Development of a Software Tool Artifact Ontology 

The first step in this research was to identify and define the characteristics 
of software development process models and tools so that they can be used to properly 
extend the Relational Hypergraph Software Evolution Model and be used to construct an 
Object Eederation for interoperability. The approach to this portion of the investigation 
was to analyze the structure, inputs, and outputs of a small set of individual tools: 
Rational Corporation's Requisite®Pro — a requirements management tool, and the 
Software Engineering Automation Tools (SEATools) — a software development 
prototyping suite. This included performing a domain analysis (of this subset of tools) 
and building a feature model of that domain [CZAROO]. Next, the main artifact attributes 
were considered in the context of the objects needed for establishing an Object 
Eederation. Using this context the characteristics were holistically defined within a 
software development tool ontology [USCH96]. The bulk of this portion of the 
dissertation research is presented in Chapter III. 

b. Integration of QFD and the Evolution Model 

Actually embedding key portions of the QED methodology within the 

Relational Hypergraph model required an examination of requirements prioritization, 

requirements uncertainty, project risk, performance trade-offs between software 

specifications, and appropriateness of software metrics to measure outcomes. Next, 

additional objects and attributes were added to the hypergraph model to account for QED 

dependencies. The correlation weightings that form the core of QED were captured as 

edge weights in the Relational Hypergraph model and priority weightings were 

established as additional component attributes to be deployed among the software 

artifacts. The hypergraph requirements model was integrated with the IBIS (Issue Based 

Information System) evolutionary prototyping model from [IBRA96] which stemmed 

from the seminal work of [KUNZ70]. This model links the requirements to their 

rationale, which consists of the positions of various stakeholder groups on the relevant 
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requirements issues, and is useful for negotiating and resolving differenees on 
requirements issues between different stakeholders. This is a qualitative model. One of 
the objectives in integrating the hypergraph model with QFD was to provide quantitative 
models of priorities that are sensitive to dependencies and disagreements among 
stakeholders. However, one of the weaknesses of QFD is its general treatment of the 
requirements as independent entities in the mathematical analysis. In reality, 
requirements are subject to a complex set of interdependencies that are captured by the 
hypergraph model. By integrating the two models, both aspects (qualitative and 
quantitative) are now available for decision support. The bulk of the research supporting 
this portion of the dissertation is presented in Chapter IV. 

c. Creation of a Federation Interoperability Object Model 

Young presents an Object-Oriented Model for Interoperability (OOMI) of 
heterogeneous systems [YOUNG 1, 02a, 02b]. He developed this model for use in 
establishing interoperability of military C4I systems. However, in this research this same 
model was applied to a different domain — the interoperability of software development 
tools and models. The OOMI relies on the collection of real-world entities used to define 
the interoperation of a specific collection of systems, which is called a Federation 
Interoperability Object Model (FIOM). The software development tool ontology 
provided an object framework from which a partial software development tool FIOM was 
constructed. The partial FIOM contained relationships between classes, packages, 
interfaces, and other elements used in the software process models and tools. Next, the 
FIOM was integrated with the extended evolution model to form an implementation of 
the HFSE. This portion of the dissertation research is presented in Chapters V and VI. 

d. Prototype the HFSE by Extending CASES 

The fourth major task in competing this research involved developing a 

proof of concept computer aid that was later used to demonstrate the software 

engineering contributions presented in the dissertation. The work here relied on 

extending a previous software evolution system — the Computer-Aided Software 

Evolution System (CASES). The main extensions to CASES involved: providing a 

graphic editor so that a user could define their own unique software development process, 

embedding QED into the evolution system so that artifact dependencies could be defined 
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and deployed throughout the software development effort, and providing user-seleetable 
views that isolated partieular "sliees" of the underlying hypergraph — providing software 
engineering informative deeision support. The extensions to CASES are presented in 
Chapter VII and use eases for CASES are presented in Appendix A. 

e. Application of the HFSE to a Software Development Scenario 
The last major task in the dissertation researeh was to apply the HESE in a 
software development seenario to provide eonfirming evidenee for the researeh 
hypothesis. Here, Requisite®Pro and SEATools were unified by the HESE and applied 
to a partieular software seenario. This seenario involved using a speeified set of software 
requirements (speeified within Requisite®Pro) for the Computer Aided Resuseitation 
Algorithm (CARA) software for a easualty intravenous fluid infusion pump. Next, the 
seenario required using SEATools to eonstruet a software prototype that embodied those 
requirements. The interoperability benefits provided through the use of the HESE in this 
software development seenario were reeorded and provide eonfirming evidenee is 
support of the dissertation hypothesis. 

The dissertation experiment is a statie group eomparison in whieh a small 
representative subset of tools/models was used to show that the HESE ean be used to 
unify them and that the interoperability of the subset of tools was improved. Campbell 
and Stanley [CAMP63] point out that this eomparison is best eharaeterized as a pre¬ 
experiment beeause it falls short of an unbiased applieation of the seientifie method. The 
results (and shorteomings) of this experiment are presented in Chapter VIII. 

C. OVERVIEW OF THE HOLISTIC FRAMEWORK FOR SOFTWARE 
EVOLUTION 

The Holistie Framework for Software Engineering is both a eoneeptual 
framework for establishing interoperability between software development tools as well 
as a methodology (with tool support) that assembles the neeessary objeets and 
interoperability eonstruets. The HFSE was established by embedding the relevant 
portions of the QFD methodology into the already existing Relational Hypergraph 
Computer-Aided Software Evolution model and then integrating this extended evolution 
model with a FIOM ereated from the tools and models used in software development. 
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1, Software Evolution 

Central to this holistic framework is software evolution. A software evolution 
system must provide strong version control of all artifacts produced during system 
development as well as track the dependencies of artifacts. In small projects (which, as a 
rule of thumb [MCBR02] characterizes as requiring less than 100 man-years of effort) it 
is less expensive to scan through the application for the impact of a change than it is to 
slow the project down by insisting on complete requirements traceability. However, for 
large software engineering projects requiring over 100 man-years of effort, the trade-off 
is exactly the opposite. Traceability of all requirements must occur because it is 
prohibitively expensive to filter through all of the design documents for the impact of a 
change [MCBR02]. 

In distributed development environments, an evolution control system must 
support collaboration between multiple users at multiple sites, support concurrent updates 
that split development threads into parallel variants, provide mechanisms for notification 
when changes made by one developer affect the work of another, and when appropriate, 
provide guidance for decoupling or serialization when on-going work of one developer 
would be counter-productive to attempted work by another. The artifacts to be controlled 
in the holistic framework vary in both purpose and format. Examples include 
organizational policy and vision documents, business case documents, development 
plans, evaluation criteria, release descriptions, deployment plans, status assessments, 
user's manuals, requirements and specifications, customer interviews, meeting minutes, 
code, software documentation, software architecture documentation, unit tests, test cases, 
and test results. The formats of these artifacts include data base entries, text documents, 
spreadsheets, images, drawings, audio files, and video clips. A long-term goal of the 
HFSE is to establish positive control and integration over this diverse set of information. 

By relating inputs and outputs of various software process models through an 
evolution interface that attaches and records the dependencies among evolution artifacts, 
information required by various processes can be automatically generated and obtained as 
needed. Such a model requires interaction between a GET, an evolution control 
component, and an object model component. The holistic framework can be viewed as 
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an abstract layer of activity that interacts with subordinate software development tools via 
middleware communications mechanisms (see Figure 3). 



Figure 3 Holistic Model of Software Process Interaction 


In the HFSE, the software engineer does not serve as a central bridge between 
subordinate software development tools, in contrast to Figure 2. However, [MCBR02] 
pointed out earlier that totally removing the engineer from the development process and 
automating all central processes is impossible. Thus, the HFSE as presented in this 
dissertation will only partially achieve the configuration shown in Eigure 3. 

The Evolution Model and Object Model interact with subordinate software 
development tools and processes. There are numerous research considerations that must 
be addressed when establishing this higher-level holistic framework. These include 
identifying standards for representation and interpretation of information, establishing the 
medium of communications, accounting for process order, providing missing data, 
accounting for ambiguity of inputs and outputs, accounting for conflict resolution 
between models, and providing for extensibility. 

The evolution interface was developed so that it can automatically deploy a range 
of artifact dependencies throughout the lifetime of a particular software project. The 
interface was established by extending the preexisting Software Evolution model 
[HARN99c] with Quality Eunction Deployment (QFD) to introduce a continuum of 
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dependencies between software artifacts [HAUS88] [HAAG96]. The preexisting model 
relies on predefined artifacts and limited dependency tracking. A QFD continuum 
separates relevant dependencies/priorities from noisy data and is an improvement over 
the previous model [HARN99c] that only provided primary and secondary dependencies 
with no articulation as to importance or strength of the dependency to the rest of the 
design. The HFSE also distinguishes the types of the dependencies and provides 
semantics and standard interpretations for the dependencies to enable tools to take 
automatic actions based on them. These extensions improve the vertical, horizontal, and 
temporal dependency graph between software artifacts (e.g. horizontal: requirement 1.2 
to requirement 1.2.1; vertical: specification 1.2 to code segment 3.4; temporal: reuse 
component 4.2 of version 1.0 to reuse component 4.2 of version 1.1). 

2. Object Model 

The interaction framework between the subordinate process models and the 

extended evolution model was constructed using the Object-Oriented Model for 

Interoperability (OOMI) for resolving representational differences between 

heterogeneous systems [YOUN02b]. This approach establishes a high-level Federation 

Interoperability Object Model (FIOM) that facilitates the interaction between the objects 

of existing heterogeneous systems. By establishing such an object federation between 

existing process models (or their tools) and then integrating that federation with the 

extended evolution model, inputs and outputs between the subordinate models (or tools) 

are available to each other while at the same time reporting interaction to the extended 

evolution model. The framework ontology provides mappings between the subordinate 

models that preserves those properties that the associated tools depend on. This research 

helps clarify some of the tradeoffs between interoperability via conformance to a single 

global data standard versus the use of multiple representations, ontologies, and 

translations as supported by the FIOM approach. This approach appears viable because 

global agreements on standards are nearly impossible to achieve in complex domains like 

software development, and they appear to be unnecessary. The FIOM ontology is used to 

identify the localized agreements and correspondences necessary at each tool boundary. 

This approach works because the localized agreements are independent of each other and 

each is much simpler than the effort required to establish a global data standard. In 
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addition, this approach accommodates local representations that are optimized for 
partieular tools. 

Onee the evolution model was extended and an interaetion framework 
established, it was possible to improve the effieieney and effeetiveness of software 
development in a number of ways. First, the entire proeess of software development 
beeame more automatie. As long as model/tool inputs and outputs are supplied through 
the holistie model, different tools were able to interaet automatieally, with less 
involvement by the software engineer. Seeond, beeause all artifaets within the holistie 
model are traeked together as a large dependeney graph, it was possible to extraet seleet 
"shoes" of the dependeney graph for partieular purposes, allowing "fooused" software 
development. For example, sinoe the holistie model interaots with existing proeess 
models for software risk management, it was possible to extraet a "shoe" of the entire 
dependeney graph (a shoe that represents the greatest risk) so that prototyping and 
analysis effort was not wasted on developing artifaets that were already well defined, 
understood, and/or were suooessfully implemented in previous versions. 

3. The Ideal HFSE 

This dissertation researoh represents an initial investigation into the oharaoteristios 
needed to establish the HFSE. As suoh, it is useful to oonsider all the ideal oharaoteristios 
of a Holistie Framework and then to disouss that subset of these oharaoteristios that will 
aotually be addressed (in whole or part) in this initial investigation. 

a. Generic 

The HFSE should be generio and non-proprietary. The framework should 
allow any model or tool to be inoorporated. The framework should not be established 
solely for use with a speoifio group of tools. 

b. Real Tools 

The HESE should support real software development tools. The 
framework should not be established simply to support researeh/laboratory software 
development tools but must aeeount for tools used to build real software. 
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c. Process Independent 

The HFSE should be independent of the software development proeess. 
The framework should be of benefit irrespective of the software process models 
employed.. 

d. Domain Independent 

The HFSE should be applicable to linking together tools irrespective of 
the software domain to which they are applied. 

e. Extensible 

The HFSE should be extensible. Not only should it be possible to include 
new process models or tools by using the framework, but it should also be possible to 
modify or update the attributes of the framework based on new technologies or new 
attributes required by new process models. The ideal HFSE will not have attributes that 
must be modified when it is extended - the goal is to enable extensions that refer to only 
adding more attributes, without changing the information you have, except possibly 
dropping some that may not be relevant in some contexts. 

In order to maximize profit, software applications are required to 
effectively operate for years. Such longevity requires consideration of software tools and 
languages that also have similar longevity — or if that is not possible, then consideration 
must be made to provide a stable long-term development environment in which tools are 
replaced when required. [MCBR02] states: 

Eong-lived applications require long-lived development tools... A key 
question that needs to be asked when considering long-lived applications 
is whether your development tools are likely to remain stable for the 
lifetime of the application. This question can be really tough to answer, 
but we need to start thinking about it because the 1990s were littered with 
tools that have not survived. How would you act differently if your users 
insisted that the application has to be useable for the next 20 years, just 
like any other capital asset? 

Thus, the HFSE should provide an environment within which tools can be switched out 
or replaced to provide developers a long-lived, stable support environment for long-lived 
applications. 
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f. Improve Time to Market 

Use of the HFSE should improve the likelihood that software is produeed 
in a timely manner. It should be possible to demonstrate that applieation of the HFSE to 
a set of development tools will actually decrease the amount of time that is required to 
produce and implement specific software functionality of interest. 

g. Decrease Cost of Development 

Use of the HFSE should decrease the cost of developed software. It 
should be possible to demonstrate that application of the HFSE to a set of development 
tools will actually decrease the cost required to produce and implement the target 
software functionality. 

h. Improved Quality 

Use of the HFSE should increase the quality of developed software. It 
should be possible to demonstrate that application of the HFSE to a set of development 
tools will actually produce software that is of better quality than software produced by 
tools that have not been subject to integration by the HFSE. 

L Easy to Use and Enhances Productivity 

The HFSE should be intuitive and easy to use. It should be possible to 
demonstrate that the HFSE is easy to use with attendant high-levels of productivity. 

4, Scope of the Dissertation Research 

Of these ideal HFSE characteristics, only items “a” through “e” will be directly 
addressed and confirmed by this dissertation research. Items "f-i" will be discussed in the 
dissertation, but formal validation of these characteristics is left to future research. 

D, CONTRIBUTIONS PROVIDED BY THIS DISSERTATION 

1, Accomplishment of the Research Goal 

This dissertation provides confirming evidence of the research hypothesis. In 
particular, this dissertation demonstrates the following; 

a. Construction of the HESE is Eeasible 

It is feasible to establish a Holistic Framework for Software Engineering 
that consists of an extended Software Evolution model integrated with a Federation 

Interoperability Object Model of subordinate software development models and tools. 
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b. HFSE Artifacts Can be Described Mathematically 

It is feasible to mathematieally deseribe the HFSE eonstruets. 

c. The HFSE Increases Software Tool Interoperability 

The applieation of the HFSE to a sample set of software development 
tools (i.e., Requisite®Pro and SEATools) inereases the interoperability (i.e., data 
exehange and joint task exeeution) of the seleeted set. 

2, Other Original and Unique Contributions 

While the most important original eontribution to the field of software 
engineering that this dissertation provides is to establish the feasibility of the HFSE, there 
are several other eontributions. 

a. Develop a Software Development Tool Ontology Construction 
Methodology 

This dissertation provides the blueprint for building a software 
development tool ontology. The methodology was adapted from other sourees (notably 
[USCH96]), but was tailored for identifying and eapturing the unique eharaeteristies of 
software development tools. This methodology ean be used to add software development 
tools to a tool ontology. 

b. Construct a Pilot Software Development Tool Ontology 

This dissertation presents a partial software development tool ontology. 
Three separate ontologies (and their inter-relationships) are presented: a high-level 
software development tools ontology, an ontology that deseribes the Common Objeet 
Model (COM) interfaee of Requisite®Pro, and an ontology that deseribes important 
(from an interoperability viewpoint) elasses from SEATools. Together, these ontologies 
form the basis for the Federation Entities in the software development tool FIOM. 

c. Adapt QFD Methodology to Deploy Software Dependencies other 
than Quality 

This dissertation demonstrates a methodology for deploying definable 
software dependeneies throughout a software development effort. To date, the main 
software dependeney deployed using QFD has been a eustomer's view of quality. While 
the theoretieal deployment of other dependeneies (e.g., eost, reliability, new technology. 
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security) have been suggested by other authors, there are no published proposals for 
deploying these other dependencies. This dissertation presents such a proposal. 

d. Apply OOMI to the Software Development Tool Domain 

The OOMI was applied to an entirely different domain (other than C4I 
systems) by establishing a FIOM between software development process models and 
tools. This effort provided an appreciation of the difficulties in applying Young's 
methodology to a set of legacy heterogeneous software systems. 

e. Use the HFSE to Provide Perspective Views of the Development 
Effort 

This dissertation provides tool support that provides user defined 
perspective views of particular aspects of a software development effort. These views 
allow the user to glean important decision support information from the underlying 
hypergraph of the software development effort. Such decision support can be later shown 
to provide software process and product improvements. 

E, ORGANIZATION OF THE DISSERTATION 

This dissertation is organized to progressively take the reader from the theory 
underlying the HFSE, through the research that led to the development of the framework, 
and through the efforts to provide tool support for the effort. The dissertation culminates 
in the application of the framework against a non-trivial software development scenario. 

Chapter II presents a survey of previous work on developing interoperability 
among heterogeneous software development tools. The chapter consists of two main 
sections. First, a "Foundation Work" section identifies the key research upon which the 
HFSE research is founded. Examples of this foundation work include software evolution, 
the Relational Hypergraph model of software evolution. Quality Eunction Deployment, 
and the Object-Oriented Methodology for Interoperability. The second major section in 
this chapter covers "Related Work" — the areas of research that are in some way in 
competition with the premise of the HESE. Examples of related work include software 
development tool suites, unified processes, and other efforts to form Integrated Software 
Development Environments (ISDEs). 
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Chapter III provides the methodology and work associated with establishing the 
software development tool ontology upon which the HFSE depends. It lays out the 
methodology used to identify and organize the terminology of the software development 
tool domain. It presents the captured ontologies of the two specific tools used in the 
HFSE research. 

In Chapter IV the integration of the Relational Hypergraph Model of Software 
Evolution and Quality Function Deployment is discussed. The chapter explains the 
theory behind both models and lays out the mathematical relationships of their integration 
and the mathematical basis upon which the user-defined perspective views are formed 
from the underlying hypergraph of the software development effort. 

Chapter V introduces how the OOMI methodology was applied to the domain of 
software development tools. It presents the construction of a partial FIOM between 
Requisite®Pro and SEATools. It discusses the difficulties associated with intralingual 
translation approaches and what is required to extend the software tool FIOM to include 
other development tools such as Rational Rose. 

Chapter VI presents the resulting HFSE. It describes the HFSE and lays out the 
way in which a software engineer would apply the HFSE in a given software 
development scenario. The chapter discusses how the HFSE could be extended to 
incorporate additional software development tools. Finally, the chapter presents the 
theory behind how the HFSE could be applied in a given situation to provide an engineer 
with decision support information related to the development effort. 

Chapter VII introduces the tool support of the HFSE (CASES). It explains what 
version 1 of CASES did and provides details on the many enhancements to CASES so 
that it now supports application of the HFSE. Examples are shown of how to graphically 
develop project schemas, register components with external software development tools, 
construct complex QFD dependency matrices and finally, take slices of the underlying 
Relational Hypergraph to provide a meaningful subgraphs that form the basis of the 
decision support the HFSE provides. 
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Chapter VIII presents the Hello World and CARA Infusion pump software 
scenarios. The chapter lays out how the HFSE was applied in the scenarios to provide 
confirming evidence of the dissertation hypothesis. 

Chapter IX concludes the dissertation by providing a summary of the 
contributions of the work as well as pointing researchers towards areas of future 
investigation. 
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II. PREVIOUS WORK 


A. CHAPTER ORGANIZATION 

This chapter is organized into two main sections: "Foundation Work" and 
"Related Work." The "Foundations Work" seetion foeuses on that previous researeh that 
establishes the underpinning of the investigations presented in this dissertation. The 
purpose of the seetion is to provide a starting place, baekground, and basis upon which 
the eontributions of this dissertation are founded. The "Foundation Work" seetion is 
organized into the following areas: 

• Approaches to Software Evolution, 

• The Relational Hypergraph Evolution Model, 

• Quality Eunction Deployment, 

• The Objeet-Oriented Model for Interoperability, and 

• The Use of Ontologies in Establishing Interoperability. 

The "Related Work" section of this chapter presents research that attempts to 
aeeomplish some of the same aims and objeetives as those resolved in this dissertation. 
The presentation in this seetion eompares and eontrasts these other works with the work 
and aecomplishments presented in this dissertation. The "Related Work" seetion is 
organized into the following areas: 

• Software Development Tool Suites, 

• Unified Software Development Proeesses, 

• Integrated Software Development Environments, 

• Previous Use of Ontologies in Software Development, and 

• Previous Use of QED in Software Development. 

Together, these sections provide a comprehensive literature review of the topics 
presented in the dissertation and clearly show the basis upon which this work is founded 
as well as deseribing how it differs from previous efforts. 


B, FOUNDATION WORK 

1, Approaches to Software Evolution 

Over the years "Software Evolution" has beeome a reeognized and well- 
established subfield of software engineering. [EUQI89] states that: "Software evolution 
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refers to all aetivities that change a software system, including responses to requirements 
changes, improvements to performance or clarity, and repairs for bugs." This implies 
that software evolution includes more than just software maintenance, requirements' 
traceability, and configuration control; it is a recognition that a software product is 
subject to long-term (birth to retirement) modification in order to meet changes in 
environment and changes in customer needs. It is also a recognition that all aspects 
related to this continual, progressive, and evolutionary change may have an impact on 
how much change is possible, that rate at which change is possible, and how successful 
that change is in the eyes of the customer. 

In his seminal work in researching the problems in the evolution of IBM's 
software products (and the evolution of the OS/360 in particular), Lehman proposed a 
new paradigm for dealing with the problems of size and complexity in ever-evolving 
software systems [LEHM69]; 

The [software crisis] implies the need to replace existing unstructured 
technology-oriented programming methodology by an overall total- 
process-oriented methodology. This is seen as providing a structure to the 
process. This structure must be designed to guide the programming 
process and enable it to achieve any desired combination of the 
performance, reliability and cost for a minimum in human effort and 
maximum machine support... By creating an appropriate structure for the 
process itself, complexity and cost are reduced, and human and machine 
effectiveness simultaneously increased. 

It is interesting to note that even as early as 1969, Lehman recognized the need for taking 
a holistic approach to software development, recognizing that it was not enough to simply 
improve individual aspects of the software development process or individual software 
development tools. He stated that the software development process "is itself a 'system' 
involving many people, many phases, many components and many requirements. A 
characteristic feature of systems is that local subsystem optimisation does not lead to 
system optimisation. Thus investigation and improvement of a part of the process 
without consideration of the process as a whole demands extreme care" [LEHM69]. 
Consequently, it is through the development of holistic development environments (such 
as that provided by the HESE) that significant progress can be made in providing 
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enduring customer satisfaction in the face of the inevitable evolutionary change that 
accompanies any software project of significant size and complexity. 

Much of Lehman's work has focused on treating large, long-duration software 
products as feedback and control systems subject to real-world forcing and damping 
functions (e.g., new customer demands, developer's insertions of new code and 
modification of existing code, budgetary constraints, changing technology, etc.). To 
illustrate Lehman's concept, consider an imaginary software system from birth to death, 
as depicted in Figure 4. 



Figure 4 Software Evolution as a Feedback and Control System 

From the developer's viewpoint, the developer is always trying to attain and maintain a 
constant level of customer satisfaction. From the customer's viewpoint, that constant 
level of satisfaction translates into an ever-increasing amount of demanded utility from 
the system. While over time, demanded utility is shown here as linearly increasing, this 
could actually be increasing non-linearly based on market competition and new user 
needs. The software that is delivered determines the customer's actual satisfaction level 
(how useful it is in comparison to the customer's needs, how it matches the customer's 
expectations, etc.). At the same time the actual level of satisfaction is negatively 
influenced by both internal factors (e.g., defects, poor documentation, etc.) and by 
external factors (e.g., competitor's products that are perceived to be better, obsolesce of 
hardware, etc.). Unfortunately while these internal and external forces are not necessarily 
bounded, it remains incumbent on the developer to account for them anyway: "Exploiting 
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this multidimensional unboundedness is an inevitable eonsequenee of eomputer usage" 
[LEHM98]. 

Mueh of this "unboundedness" is eaused through impreeision and obsoleseenee of 
natural language expressions of stakeholder desires, as well as the problem of stated but 
misunderstood, improperly stated, or unstated assumptions. [BERZ91] points out that one 
of the main ehallenges of software evolution in traditional eontexts is the laek of aeeuraey 
in requirements, speeifieations, and design doeuments. [EE1QI89] eontinues by pointing 
out that the developer must have preeise doeumentation to reliably ehange the system. 
Unfortunately in the ease of older systems, sueh doeumentation (other than the souree 
eode) typieally does not exist, has been lost, or is obsolete beeause of the large amount of 
time and effort required to manually ereate and maintain it. In the ease of assumptions 
[EEHM98] observes that: 

The sourees and nature of the assumptions are eountless (I have estimated 
that a typieal program has about one real-world assumption for every 10 
lines of eode). Some of these assumptions will remain valid throughout 
the system's life; others will be invalidated by subsequent ehanges in the 
applieation or its operational domain. Still others will fall somewhere in- 
between: valid in some eireumstanees, but leading to unaeeeptable results 
or behavior in others. Sueh invalidity generally remains undeteeted until a 
problem arises or a disaster... 

An additional souree of unboundedness arises from what [EEHM91] terms as "Gddel- 
like" and "Heisenberg-like” uneertainties. In Godel-like uneertainty, the real-world 
software system (ineluding its users and developers) ean be viewed as a model of some 
desired fimetionality operating in an infinite universe. The users and developers (who are 
aetually part of and internal to the model) eannot eompletely know the properties of the 
model and its interaetion with the external universe — their knowledge is ineomplete. In 
Heisenberg-like uneertainty, implementation of the software system ehanges the 
operating environment of the system. Onee users gain first-hand experienee of the 
system, their expeetations of what the system is supposed to do fundamentally ehange. 
Unfortunately, total eontrol of assumptions and uneertainty ean never be aehieved; but, 
"there ean and must be signifieant improvement in the manner in whieh sueh matters are 
eontrolled in eurrent industrial praetiee" [LEHM91]. 


28 



One way to tackle this problem is to do a better job of recording application and 
domain boundaries. [LEHM98] suggests that such decisions should be recorded in a 
structured fashion that also displays the recognized dependencies and relationships 
between them. Developers must recognize, capture, and record assumptions, whether 
explicit or implicit, in design and implementation decisions. They must also record any 
dependencies and the relationships between them. The HFSE provides the developer a 
framework for recording these assumptions and dependencies. But it is not enough to 
simply record these assumptions and relationships, proposed changes to a software 
system must be examined in relation to the assumptions to ensure that intended behavior 
is achieved. 

Eehman's continuing and voluminous body of work in the field of software 
evolution has led to the development of what are now known as Eehman's Eaws of 


Software Evolution, summarized in Table 1 below [EEHM97]. 


# 

(Yr) 

Title 

Description 

I 

(’74) 

Continuing Change 

Software systems must be continually adapted else 
they become progressively less satisfactory. 

II 

(’74) 

Increasing Complexity 

As a software system evolves its complexity increases 
unless work is done to maintain or reduce it. 

III 

(’74) 

Self Regulation 

A software systems' evolution process is self¬ 
regulating with distribution of product and process 
measures close to normal. 

IV 

(’80) 

Conservation of 
Organizational Stability 
(invariant work rate) 

The average effective global activity rate in an 
evolving software system is invariant over the product 
lifetime. 

V 

(’80) 

Conservation of 
Familiarity 

As a software system evolves all stakeholders (e.g., 
developers, sales personnel, users, etc.) must maintain 
mastery of its content and behavior to achieve 
satisfactory evolution. Excessive growth diminishes 
that mastery. Hence the average incremental growth 
remains invariant as the system evolves. 

VI 

(’80) 

Continuing Growth 

The functional content of software systems must be 
continually increased to maintain user satisfaction over 
their lifetime. 

VII 

(’96) 

Declining Quality 

The quality of software systems will appear to be 
declining unless they are rigorously maintained and 
adapted to operational environment changes. 
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# 

(Yr) 

Title 

Description 

VIII 

(’96) 

Feedbaek System 

Software evolution proeesses eonstitute multi-level, 
multi-loop, multi-agent feedbaek systems and must be 
treated as sueh to aehieve signifieant improvement 
over any reasonable base. 


Table 1 Lehman’s Laws of Software Evolution (after [LEHM97]) 


These "laws" and years of observation have led Lehman and others involved in 
the FEAST (Feedbaek, Evolution, and Software Teehnology) Researeh Group to begin 
work in trying to define a theory of software evolution, eonsistent with empirieal 
evidenee eolleeted to date [LEHMOO]. EEAST has been primarily eoneemed with the 
"properties of the evolution phenomenon, the what and the why of evolution." The group 
has sought to understand the software evolution phenomenon by applying the seientifie 
method of observation, measuring, modeling, interpretation, and hypothesis generation 
with a primary goal to "determine the underlying causes, attributes and praetieal impact 
of evolution" on software development proeesses and produets. This is different than the 
view taken in this dissertation in whieh the eoneern foeuses on "the how of evolution" 
and in partieular on how the improvement and management of the evolution proeess ean 
lead to higher produetivity, improved quality, faster development, greater adaptability 
and reliability, ete. "Those interested in the why and the what see evolution as the sum 
total of aetivity required to maintain stakeholder satisfaetion over applieation lifetime. 
Those that foeus on the how see it as the process to aehieve satisfaetory, eontrolled and 
diseiplined software ehange" [EEHMOO]. 

In summary, there are five important eoneepts in how others have taekled the 
domain of software evolution that are important to this dissertation. Eaeh of these is 
listed below with the implieation to the HFSE highlighted. 

a. Inevitability of Evolution 

Software of any signifieant size or eomplexity will inevitably require 
modifieation in order to eontinue to provide eustomer utility. HFSE implication: The 
HFSE traeks and reeords many artifaets and potentially even more relationships between 
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artifacts over great periods of time. The framework provides the software engineer an 
easy and effieient way to "browse" through these artifaets and relationships. 

b. Holistic Approach 

Improvements to individual parts of the software development process 
without regard to the whole proeess do not guarantee overall improvement in process or 
product. HFSE implication: The HFSE is holistic in nature. It is able to traek artifacts 
and relationships throughout the entirety of the software development effort. It provides 
the engineer the ability to view specialized information across this entirety. 

c. Assumptions and Uncertainty 

Imprecise and inadequate doeumentation, uneertainty and ineompleteness 
of software modeling, and unstated/misstated/obsolete assumptions ereate a natural deeay 
in software quality. Lehman's 2"*^, 6*, and 7* Laws imply that preventing the decay 
requires more and more of the total software maintenanee effort over time. HFSE 
implication: The HFSE provides the engineer the ability to recognize, capture, and 
record assumptions, whether explicit or implicit, in design and implementation decisions. 
Furthermore the HFSE provides the engineer the ability to reeord assumption 
dependencies and the relationships between the assumptions and other software artifaets. 
It is not enough to simply reeord these assumptions and relationships, the HFSE allows 
the engineer to examine proposed ehanges to a software system in relation to the 
assumptions to ensure that intended behavior is achieved. Unfortunately, the HFSE does 
not directly correct the "unstated or mis-stated" assumption problem; however, it does 
provide the engineer a powerful framework for isolating and then identifying such 
problematic assumptions. 

d. Validation Against Assumptions 

Software engineers must have better meehanisms that allow them to 
eontinually validate the eurrent state of the software against previously stated (and 
unstated/mis-stated) applieation boundaries and assumptions. HFSE implication: the 
HFSE provides the engineer the ability to select specific subsets of information traceable 
to the current design. These "views" give the engineer insight into how their current 
software artifacts match up against previously produced artifacts (including assumptions). 
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e. Views of Evolution 

Software Evolution can be seen from two points of view: those interested 
in why evolution occurs and what causes it, and those interested in how evolution can be 
managed to produce improvements to software processes and products. HFSE 
implication: The HFSE seeks to implement the second view of evolution. It provides a 
framework by which software processes and products can be improved (however, recall 
that this dissertation only seeks to prove the feasibility of the HFSE and proof of 
improvement is considered future research). 

The implication of these five concepts to the development of the HFSE is 
significant. Software evolution forms the core of the framework providing the software 
engineer a mechanism by which he can record assumptions, relationships, and 
dependencies and then easily isolate important decision support information. 

2, The Relational Hypergraph and CASES 
a. Brief History of the Hypergraph 

Claude Berge first introduced the hypergraph in 1960 as a way to 
generalize graphs [BERG89]. In particular, he defined a hypergraph H as shown in 
Equation 1. 

H = (V,E) 

where 

V = {Vj, Vj,..., } is the set of n vertices (or nodes) Equation 1 
E = {E^,E^,...,E^ \ E.^Y for/ = l,...,m} 
is the set of m hyperedges 

An undirected hyperedge Et represents a relationship involving all the vertices in the 
subset of Ei. Given this definition, it is easy to see how this generalizes previous 
definitions of graphs, because a typical graph where each undirected edge connects two 
nodes would be the special case of a hypergraph such that the condition in Equation 2 
holds. 

|E'.| = 2 Vz Equation 2 

In a directed hypergraph, two additional functions are defined on the hyperedges (T(E) 
and H(E)) to distinguish the "tail" vertices of the hyperedge and the "head" vertices. It is 
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then straightforward to produce an incidence matrix A = (a,y) defined by Equation 3 that 
records all necessary information about the hypergraph. 


a,j = < 


-1 ifv,eT(E^) 
1 ifv,eH(E^.) 
0 otherwise 


Equation 3 


Eigure 5 illustrates a directed hypergraph with its associated incidence matrix. 




Ei 

E2 

Es 

1 

-1 

0 

0 

2 

-1 

0 

0 

3 

-1 

0 

0 

4 

1 

-1 

0 

5 

1 

0 

0 

6 

1 

0 

-1 

7 

0 

1 

0 

8 

0 

1 

1 


Figure 5 Directed Hypergraph with Incidence Matrix 


Since the introduction of hypergraphs, hypergraphs have been used in 
numerous cases in combinatorics and computer science and more recently in the area of 
software evolution. 

b. The Relational Hypergraph (RH) Software Evolution Model 

Ham, in his PhD dissertation [HARN99c], extends the work of several 
others [BORI86], [EUQI90], [BADR93], and [IBRA96] in establishing a Relational 
Hypergraph model (RH model) to describe software evolution. This model establishes 
dependencies and links between key activities/artifacts of a software development cycle 
and also between sequential iterations of cycles. The model allows the development of 
tools to manage both the activities in a software development project and the products 
that those activities produce. An example of such a tool is the Computer Aided Software 
Evolution System (CASES) developed at the Naval Postgraduate School in support of 
Ham's work, 

CASES, programmed in Java, is a software system that performs the 
following key functions during software evolution; control, management, formation. 
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refinement, traeeability, and assignment. CASES manages and eontrols all of the 
aetivities that change a software system and the relationships among these activities. 
CASES is based upon the relationships in the evolutionary process model shown in 
Eigure 6. 



Figure 6 Software Evolution Processes with CASES (from [HARN99c]) 


Underlying CASES are software evolution models that use the relational hypergraph to 
mathematically characterize the relationships between software activities and artifacts. 
Ham adapts Berge’s hypergraph [BERGS 9] to establish a hypergraph model, 
evolutionary hypergraphs, and relational hypergraphs as follows [HARN99c]; 

A hypergraph model represents the evolution history and future plans for 
software development as a hypergraph. Hypergraphs generalize the usual 
notion of a directed graph by allowing hyperedges, which may have 
multiple output nodes and multiple input nodes. 

An evolutionary hypergraph is a directed, labeled hypergraph that has 
been annotated with the attributes of the evolutionary components and 
steps of a software development process. 
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A relational hypergraph is an evolutionary hypergraph in whieh the 
dependency relationships between components and steps can have a 
hierarchy of specialized interpretations. 

In the Relational Hypergraph, activities and artifacts affected by the 
software evolution process are called software evolution objects and consist of "Steps" 
and "Components." Harn identifies eight types of steps: the software prototype demo 
step (s-C), issue analysis (s-I), requirement analysis (s-R), specification design (s-S), 
module implementation (s-M), program integration (s-P), Software product demo (s-0), 
Software product implementation (s-Pd). There are eight types of components: 
Criticisms (C), Issues (I), Requirements (R), Specifications (S), Modules (M), Software 
prototype programs (P), Optimizations (O), Software product programs (Pd). The 
Relational Hypergraph model uses a hierarchical refinement (top-level objects, refined 
objects, atomic objects) to link these objects and establish dependencies (both primary 
dependencies and secondary dependencies) between the objects. 

Ham's work forms the basis for establishing a Software Evolution Model 
as the core for the HFSE. By reworking the evolution model to become more extensible, 
the Relational Hypergraph becomes a very useful mathematical constmct for establishing 
dependencies between evolution artifacts. 

Ham's work has two primary weaknesses when viewed from a perspective 
of its usefulness to developing a Holistic Framework for Software Engineering. 

(1) Eack of Generality & Extensibility. Ham's work was 
established for a single process model — the evolutionary prototyping model. While he 
demonstrated the use of this model on different domains of systems (C4I and embedded 
real-time systems) he did not demonstrate its applicability for use with other main-stream 
process models (e.g. spiral development, waterfall, Win-Win, etc.). Also, while the 
original graph model is extensible [EUQI90] (Ham's model being one of those 
extensions). Ham failed to provide a uniform method for extending the base model to 
support new process models. While it is fairly easy to add and modify components, 
steps, and attributes in his model, many of the mles governing their relationships have to 
be modified as well. The lack of generality is perhaps the reason why the model has not 
been widely adopted in industry. 
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Overcoming the lack of generality in Ham's evolution model 
requires that the model be redone within a generic framework. Constmcts are included in 
the HFSE that allow the software designer to "build" the objects, components, steps, and 
attributes that the designer actually uses in their specific software development process 
and then to link these objects together through establishment of dependency relationships 
using QFD. 

(2) Parametrical dependencies. Harn established the Relational 
Hypergraph model to only account for a limited number of dependencies between 
artifacts (e.g. Primary-input driven and Secondary-input driven). Unfortunately, this 
does not match the real world in which software artifacts are related through a continuum 
of dependencies. The HFSE defines and implements a small finite set of distinct 
meanings for dependencies. 

Embedding QFD into the model solves this shortcoming. QFD 
allows for and keeps track of a continuum of dependencies between objects (in fact, it is 
the continuum of dependencies that form the core of the QFD methodology). 

3, Quality Function Deployment (QFD) 
a. QFD History and Cited Benefits 

QFD was originally developed in Japan in the mid 1960's as a 
"requirements based" methodology that ensures that the "Voice of the Customer" is 
deployed throughout the product design and manufacturing process. The Japanese 
application of QFD in the 70's is often cited as a primary factor that allowed them to 
dominate the global automobile industry for almost a decade and in the early 80's it was 
the US application of QFD that allowed the US automobile industry to recapture some of 
its lost global market-share [CFAU88] [HAUS88]. Since then, the use of QFD has been 
extended to the entire US manufacturing industry as a means of ensuring products meet 
customer requirements. 

QFD establishes a conceptual map that provides the means for inter¬ 
departmental functional planning and communications [HAUS88]. The customer's own 
words and phrases are captured and used whenever possible. It is these words that are 
simultaneously translated by the designers, architects, programmers. One of the many 
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benefits of QFD is to enhance cross communications between departments in the same 
development effort [COHE95]; consider Figure 7. 



Figure 7 QFD Enhances Cross-Functional Communication (after [COHE95]) 

Recall the likeness of this diagram to the traditional software development diagram 
presented earlier (Figure 2). Because QFD acts a central communications mechanism for 
deploying the customer's vision of a quality product across different functional areas in a 
company, in many ways, QFD can be used to perform much of the dependency 
"bridging" that has traditionally rested on the shoulders of the software engineer. 

QFD can also help to improve product development processes. All too 
often, specialists in particular areas focus on improving their particular area of the 
process while losing sight of the holistic nature of the development effort. [CFAU88] 
states: 

When specialists polish their own specialties within their own segments, 
their activities may appear very elegant and impressive. But all too often, 
they simply lead to “institutionalization of waste.” 

An example of this was the highly touted development of automated storage and retrieval 
systems (AS/RS) that were to revolutionize the warehousing industry. While such 
systems significantly improved warehousing, they became virtually useless with the 
advent of "Just-in-Time" inventory processes in which the overall goal was not to 
speedup warehousing activity, but to eliminate it altogether. What is needed in such 
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cases is greater eross eommunieation between development segments — a need that QFD 
is designed to address. 

b. Software Quality Function Deployment (SQFD) 

While QFD has been widely and sueeessfully integrated into mueh of the 
U.S. produet industry, the same eannot be said of the integration of QFD into the U.S. 
software industry. There are a number of reasons for this laek of integration. A Japanese 
pioneer of QFD, [AKAO90] eomments that "the quality funetion deployment method for 
software development is not yet well established" and that "examples of the use of quality 
eharts [QFD matriees] for determining the quality plan and quality design are also searee. 
Identifying eritieal funetions deployed for individual software is a ehallenge to be 
addressed in the future." He states that the mueh of this problem stems from a general 
laek of quantitative measurement methods and ways to test and measure software quality. 
Measuring the frequently eited elassifieations of software quality eharaeteristies 
(ineluding objeetivity, operability, performanee, reliability, usability, eonfidentiality, 
seeurity, expandability, interehangeability, reusability, and eontinuity) has proven very 
diffieult and is a key reason that there has not been more effort to integrate QFD into 
software development proeesses. 

In diseussing the use of QFD for embedded systems, [THAC90] attributes 
the laek of integration of QFD into software proeesses partly beeause of ineompatibility 
between the terminology used in QFD and the terminology used in software. Also, that 
while many software eompanies are trying to implement simultaneous (or eoneurrent) 
software development proeesses, they are failing beeause of a laek of a definable 
eoneurrent engineering proeess. The reason seems to be the laek of a eonsistent and 
properly doeumented proeess that eovers all aspeets of software development while 
simultaneously addressing the diseipline of embedded systems development and is tied to 
the organizational strueture of the eompanies eonstrueting the embedded software. 
While Data Flow Diagrams and Control Flow Diagrams are used widely in embedded 
systems design, they have a number of shorteomings [THAC90]; 

• They do not show whieh eomponents map to whieh eustomer 
requirements. 

• They do not show potential eonfiiets in requirements. 
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• They do not show the positive or negative impaet of one design 
element on a partieular requirement. 

• They do not show the positive or negative impaet of one design 
element on another design element. 

• They do not show whieh method, tools, and proeedures are used 
for various parts of the design. 

• They do not show how the resouree plan maps to the development 
effort. 

Existing requirements analysis and speeifieation methodologies (e.g. struetured analysis 
and design, objeet modeling teehniques) do not elearly identify how software 
development tasks implement what eustomers want [LIUXOO]. Also, existing 
methodologies fail to identify and resolve eonfliets between eustomer requirements. 
QFD is a methodology that overeomes eaeh of these ehallenges when used prior to the 
ereation of Data and Control Flow diagrams. [THAC90] goes further and points out that 
for QFD to be properly integrated into existing software design proeesses, a lot more 
automation of the proeess is needed. In partieular he points out the following: 

• Produet development information should be freely and seamlessly 
available aeross all implements. 

• Software Engineers need to be able to 'browse' through engineering 
data at will and ereate new relationships where appropriate. 

• Other designer should be able to traee baek and determine 
engineering trade-offs, reasons for design deeisions, ete. 

It is these very issues related to automation that embedding QFD into the Relational 

Hypergraph model of Software Evolution (forming the HFSE) is designed to solve. 

While QFD has not yet been widely integrated into software development, 
there are cases when QFD has been used successfully in software development. 
[FIUXOO] states: 

It [SQFD] has been applied to improve software quality in many large 
organizations, such as DEC, AT&T, Hewlett-Packard, IBM and Texas 
Instruments... SQFD has been utilized in developing various types of 
software products, such as operating systems, embedded software, 
management information systems, decision support systems, network and 
transaction processing systems. SQFD has been beneficial in developing 
new software products and upgrading or enhancing existing software 
products. It helps to enhance communication between customers and 
software developers and testers. 
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In the cases where QFD has been used for software development, cited 
benefits of SQFD include the following [HAAG96]: 

• Fosters better attention to customers' perspective. 

• Creates better communication among departments. 

• Provides decision justification. 

• Quantifies qualitative customer requirements. 

• Represents data to facilitate the use of metrics. 

• Facilitates cross-checking. 

• Avoids the loss of information. 

• Reaches consensus of features quicker. 

• Reduces product definition interval. 

• Can be adapted to various Software Development Life Cycle 
methodologies. 

The benefits of SQFD appear to be synergistic and lead to fewer changes 
in requirements specification, design, and code, and reduction in the number of defects 
and less rework, and therefore, higher productivity [LIUXOO]. As QFD was initially 
invented in Japan, SQFD was also first invented and used in Japan — initially to improve 
the quality of embedded software. As reported in [ZULT93], one of the companies that 
has incorporated SQFD into their software development processes is NEC's IC 
Microcomputer Systems Company (NEC IC Micon) the first software organization to 
win the Deming prize. During the period 1982 to 1987 the 1000 person software 
organization was able to reduce shipped software defects from 45 to 0.5 defects per 
million lines of executable code, increase their productivity by 5 times, increase sales by 
5 times, thus increasing their market share by 20%, which in turn increased profit by 4 
times. 

QED, when applied to software, allows managers to focus precious project 
resources on the customer's high-value software elements and in the end, produce a better 
software development process and a better (higher quality in the customer's eyes) 
software product [ZUET92]. [EIUXOO] states: "Software Quality Eunction Deployment 
(SQED) focuses on improving the quality of both the software development process and 
the product." QED can be used to deploy not only quality, but also technology, cost, 
reliability, or any special concerns such as usability, reuse or security. The QED 
methodology provides both forward and backward traceability in the development life 
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cycle. Because the QFD proeess is flexible, engineers ean define other appropriate 
deployments to address specific concerns of customers or the development organization 
[ZULT93]. Yet, while [ZULT93] theorizes about the deployment of these other eustomer 
eoneerns (dependeneies other than quality), there is no evidenee that any formal work in 
establishing a methodology to deploy sueh dependeneies has yet taken plaee. One of the 
goals of the HFSE is do just that. 

c. The Voice of the Customer 

QFD, in its purest form, is designed to deploy the "voiee of the eustomer" 
throughout a partieuiar design. The goal is to use the eustomer's own words to "deploy" 
the eustomers' notions of what is of value in the product to every aspeet of the 
development effort of the produet. However, there may be some ambiguity (e.g. what did 
the eustomer mean by "easy to use?") and while it may take some time to ferret out 
exactly what the eustomer meant by such a phrase, the time spent in identifying and 
implementing the customer's intent will directly leads to a quality product. Key is for 
designers and engineers to avoid interpreting eustomer phrases without clear 
understanding of eustomer intent [HAUS88]. A designer or engineer's inference could 
lead the development team to taekling problems that the eustomer deemed to be 
unimportant. 

The use of QFD in eapturing and deploying quality throughout a software 

produet's lifeeyele implies a shift in the traditional paradigm of what it means to have a 

quality software produet. [LIUXOO] states that: "Software quality ean be viewed as 

conformance to software requirements from eustomers." Unstated in this quotation is the 

fact that the eustomer might not have articulated many requirements and that these 

requirements remain hidden until after an unsatisfactory product is delivered to the 

customer. Traditional approaches to software quality have relied on Statistical Process 

Control (SPC). The aim has been to minimize customer dissatisfaetion by removing 

software defeets through appraisals, iogging/oorreeting eustomer eomplaints, eompleting 

software reviews/inspeetions/walkthroughs, and performing software testing. SPC aims 

to minimize the amount of "negative" quality in software by removing sueh defeets. 

With the addition of error cause removal, it was hoped that through process 

improvement, the generation of defeets (and the likelihood that they would remain 

41 



undiscovered until after the software was delivered) would decrease. This approach also 
seeks to minimize the "negative" aspects of quality; however, such approaches do not 
guarantee that any "positive" quality attributes still remain in the software. They only 
ensure that the system is less bad, not necessarily good; consider Figure 8. 



To maximize vaiue, understand the customer 
and design positive quality into the software 


Not good enough! 

nothing wrong ^ anything right 


To minimize defects, understand the cause 
and remove them from the software 


Figure 8 The Quality Continuum (after [ZULT92, 93]) 


It is a necessary condition that defects are removed from the software, but 
it is not a sufficient condition [ZULT92]. In addition to SPC, there must be mechanisms 
built into the software development process that ensure that there are systematic, 
controlled, and traceable means of ensuring that what the customer considers to be a 
quality attribute is delivered in the final product. There must be an understanding of 
exactly what is of value to the customer and then ensure that this value is deployed 
throughout all aspects of the development effort. [ZULT90] notes that the application of 
QFD to software will help to both prevent defects, but more importantly, to input positive 
quality attributes: 


Today software engineering using [SQFD] concentrates more on 
maximizing user satisfaction from the software engineering process. The 
focus is on preventing the causes of defects by a deeper understanding of 
the user's true requirements — starting with a careful study of user and 
stakeholder wants, needs, and concerns. With [SQFD], you work 
downstream to design quality into the system, and continuously work to 
improve the software engineering process with innovation. This approach 
seeks to maximize the users' complements (positive quality). Only strong 
positives can make software so good that user boast about it — the true test 
of exciting quality. 
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It is very typical for users to have difficulty in articulating all of their 


requirements. It is the responsibility of the software engineer to "ask why five times" to 
define and analyze at a fundament level the users' requirements [ZULT90]. The engineer 
must ask why the customer does what he does, why he has the problems he has, and why 
he is able to take advantage of particular opportunities. The engineer can only develop a 
complete and consistent set of requirements after getting close to the customer and 
understanding their wants, needs, and concerns. The engineer must get a sense of how 
meeting particular requirements effects customer satisfaction. As reported in [AKAO90] 
[COHE95] and [ZULT90, 92, 93] Kano et. al. provides a model (the Kano Model) that 
characterizes requirements based on customer satisfaction (see Figure 9). 


satisfied 


user 



dissatisfied 

user 


Figure 9 Kano diagram for Requirements (after [ZULT90]) 

Expected Requirements are the "must" features that a user expects. The 


presence of these features meets their expectations, but their presence does not 
necessarily satisfy them. Often, expected requirements are so basic that customers fail to 
mention them until the software fails to perform an expected function — the customer is 
dissatisfied with the result. Normal requirements (sometimes called "revealed" 
requirements [EIUXOO]) vary in proportion to the presence of the feature. The more of a 
normal requirement is present, the more the customer likes it. An example might be 
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communications speed — the faster a system is able to oommunieate, the more a eustomer 
likes it. Exeiting requirements are features beyond the users’ expeetations and are often 
hidden. The absenee of these features generally does not eause any dissatisfaetion, 
beeause the user was not expeeting the feature in the first plaee. Exeiting requirements 
represent signifieant opportunity for the developer beeause if the developer ean identify 
and implement these features, he will signifieantly add to the eustomer's satisfaetion and 
may fill an unfulfilled niehe in the market. An example of an exeiting requirement might 
be the addition of a new feature enabled by a eomparatively new teehnology of whieh the 
user was unaware but the developer had used previously. 

[COHE95] asserts that there are two major lessons that Kano's model 
teaehes us. The first lesson is that all eustomer satisfaetion attributes are not equal. Not 
only are some attributes more important to the eustomer than others; but, some attributes 
are important to the eustomer in different ways than others. Eor example, requirements 
that are "dissatisfiers" do not matter at all to the eustomer when they are met, but they 
seriously detraet from overall eustomer satisfaetion when they are not met. The seeond 
lesson is that as [ZE1ET92, 93] pointed out earlier, the old produet quality strategy of 
responding to eustomer eomplaints is inadequate; sueh eomplaints are likely to be eaused 
by the failure of a dissatisfiers requirement being met. A quality strategy based solely on 
removing dissatisfiers ean never result in satisfied eustomers. 

The last note about obtaining the "voiee of the eustomer" is that it is 
generally not suffieient to read reports and eonduet eustomer surveys. The engineer must 
observe the eustomer in their workplaee to get a true sense of the eonditions and 
requirements of the eustomer. In the Japanese applieation of QED, this is termed as 
"going to the gemba." As stated by [ZE1ET93]: 

We must not be eontent with an abstraet knowledge of the eustomers' 
requirements, but aequire a gut-level understanding of the eontexts of the 
eustomers. Sueh knowledge does not eome from studying a thiek 
requirements doeument, running foeus groups, or faeility eonferenee room 
meetings with eustomers. It eomes only form going to the gemba. 

Contextual Inquiry (Cl) is another teehnique for gathering eustomer requirements at the 
eustomers' workplaee. [HRON93] reports that: "Digital [Corporation] has fostered a 
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technique called Contextual Inquiry, in which the product developers visit the customer's 
workplace and observe and interview various users while they are engaged in their 
normal work activities." Also, [LAMI95] draws the parallels between "going to the 
gemba" and "Cl": "In Cl, a fundamental principle is that users are to be studied in their 
normal working context ('going to the gemba.') [sic] Users are studied as they perform 
ordinary work tasks. Analysts following the Cl technique observe users working and 
record both what the users do and how they interact with their work environment." 
Whether it is Contextual Inquiry or "going to the gemba", a key portion of the QFD 
process involves the engineer obtaining a fundamental understanding of all of the 
customers' requirements by witnessing first-hand the customer in their work environment. 

d. Steps in the QFD Process 

QFD ensures that the "Voice of the Customer" is deployed beyond the 
requirements capture phase of the design and is fully embodied in the product 
specification, architecture, and production phases of the process. QFD is a stepwise 
process with results recorded in matrices that are sometimes known as "Houses of 
Quality" because of the characteristic "house" shaped matrix for recording QFD 
relationships (illustrated at Figure 10). 
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When completing the first QFD "house", QFD consists of the following steps: 

(1) Identify Requirements. Stakeholder Requirements are 
solicited and recorded on the left y-axis. In more general terms this left hand side is also 
known as the "Whats" of the design — where the "Whats" are those items that are desired. 

(2) Identify Technical Specifications. In cooperation with 
stakeholders, the requirements are then converted to technical and measurable statements 
of the software product and recorded on the top x-axis as specifications. In more general 
terms this top row is also known as the "Hows" of the design — where the "Hows are the 
ways in which the "Whats" will be implemented. 

(3) Correlate "Whats" and "Hows." The stakeholders then 
complete the correlation portion of the matrix by identifying the strength of the 
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relationships between the requirements and speeifieations. These values are known as 
"eorrelations." 

(4) Establish Priorities. Based on the stakeholder surveys (or 
other analytie means), the priorities for the requirements are established and listed down 
the right y-axis. In this dissertation these values will be more generally ealled 
"dependeney values." 

(5) Establish Interrelationships. The relationship (and the 
strength of relationship) between speeifieations is identified and recorded across the top 
(the roof) of the matrix. These relationships represent potential engineering tradeoffs 
between specifications. The engineer balances these tradeoffs in order to optimize the 
design solution. 

(6) Calculate Priorities of the "Hows." Specification priorities 
are obtained by multiplying the stakeholder requirement priority and the correlation value 
of specific specifications. These are recorded along the bottom of the matrix. 

(7) Competition Benchmarking. Competitors' products can be 
benchmarked against either the customers' requirements or the technical specifications. 

While this first QED matrix is easily constructed, the real strength of the 
QED methodology occurs after the completion of the highest-level matrix. As the project 
continues, additional matrices are established, each of which establishes dependencies 
with the original stakeholder requirement priorities. This provides visibility of what is 
important and what is not. This quality deployment process is illustrated at Eigure 11. In 
the case of a general set of QED matrices, the "dependency" that is being deployed is a 
customer's view of "quality." However, in this dissertation that dependency may be 
defined as a type other than quality (e.g. risk, security, difficulty of implementation, etc.). 
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Figure 11 Example of a Simplistic QFD Matrix Deployment 

Note that the output of one matrix becomes the input (or starting place) of the next (e.g., 
customer requirements relates to specifications, specifications relate to software modules, 
etc.). It is possible to illustrate this set of QFD matrices as a software development 
process diagram, as shown in Figure 12. 
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Figure 12 Simplistic SQFD Model drawn as a Process Diagram 

In this digraph, the circles represent the artifacts created in the software development 
process and the edges represent a software development activity that creates new 
artifacts. Later in the dissertation these artifacts and activities are more formally defined 
as "components" and "steps." 

e. Adapting QFD to Software Development 

While it is obvious that the production of software differs greatly from the 
production of hardware and other manufactured products, it is not so obvious what 
adaptations to the QFD process are required for applying QFD to software development. 
Since QFD was originally designed to deploy quality in the non-software product 
industry, it is important to identify those significant differences between software and 
non-software development and modify the QFD process accordingly. [ZULT90] states 
that the needed adaptations involve replacing the factors of material and material-based 
costs by factors of data and time (or schedule). He summarizes these changes as data 
replacing material, processes replacing functions, and time replacing cost. 

(1) Data replaces material. Because software differs from 
traditional engineering in that it is relatively free of the need for raw material during 
production, "material" in the QFD process must be replaced with the closest software 
analog of a raw resource — "data." Software is unique in product development in that it 
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can be produced directly from requirements without having to undergo a materials-to- 
manufacturing process. "Data" becomes the raw resource needed to produce software. 

(2) Processes replace functions. In the non-software product 
industry, "functions" are implemented by "mechanisms" that are made up of "parts." But 
in software, "functions" are implemented by software "processes." 

(3) Time replaces cost. Because software development is not 
based on a need for raw material, the cost of software development is almost entirely 
made up of labor costs directly tied to the time required to produce the software product. 
Thus, "time" replaces "cost" in the QFD matrices. 

Another required adaptation of QFD to the software development process 
is to decide exactly what set of deployment matrices are going to be used and how these 
matrices are to be linked. There are fairly complicated and complex schemes of matrices 
that can be used in QFD. [COHE95] and [ZULT92] attribute Akao [AKAO90] with 
producing the standard advanced book on QFD in which Akao presents what are known 
as the Akao "Matrix of Matrices". These thirty matrices form the basis of the typical use 
of QFD in non-software product development. The matrices are summarized in Table 2. 


Matrix 

"What" 

"How" 

Activity 

A1 

Voice of the Customer 

Substitute Quality 
Characteristics (SQCs) 

Construct Matrix 

A2 

Functions 

SQCs 

Construct Matrix 

A3 

SQCs 

SQCs 

Construct Matrix 

A4 

2“‘* level of Design 

SQCs 

Construct Matrix 

B1 

Voice of the Customer 

Functions 

Construct Matrix 

B2 

Competitive Analysis 

Cost 

Construct Matrix 

B3 

Detailed SQCs 

Breakthrough targets 

Construct Matrix 

B4 

Critical Parts 

SQCs 

Construct Matrix 

Cl 

New Technology 

Level of Design 

Construct Matrix 

C2 

Functions 

Level of Design 

Construct Matrix 

C3 

SQCs 

Level of Design 

Construct Matrix 

C4 

2"‘* level of Design 

Level of Design 

Construct Matrix 

D1 

Voice of the Customer 

Product Lailure Modes 

Construct Matrix 

D2 

Functions 

Product Lailure Modes 

Construct Matrix 
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Matrix 

"What" 

"How" 

Activity 

D3 

SQCs 

Product Eailure Modes 

Construct Matrix 

D4 

2“‘* level of Design 

Product Eailure Modes 

Construct Matrix 

El 

Customer Needs 

New Concepts 

Construct Matrix 

E2 

Eunctions 

New Concepts 

Construct Matrix 

E3 

SQCs 

New Concepts 

Construct Matrix 

E4 

Criteria 

New Concepts 

Construct Matrix 

El 



Value Engineering 

E2 



Reliability Analysis 

E3 



Breakthrough Planning 

E4 



Design Improv. Planning 

G1 



Quality Assurance Planning 

G2 



Equipment Deployment 

G3 



Process Planning 

G4 



Process Eault Tree Analysis 

G5 



Eailure Mode Effects Analy. 

G6 



Process Quality Control 


Table 2 Akao "Matrix of Matrices" Summary (after [COHE95]) 


The thirty Akoa QFD matrices are expected to be used as a guide and not 
to be used verbatim in all development efforts. Since each design team project will have 
different characteristics, these matrices provide a beginning for teams to create their own 
QFD Model. [ZULT90] goes further and provides a tailored set of deployment matrices 
adapted for use in engineering software as illustrated in Figure 13. 
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Figure 13 SQFD -- Deployment of the "Customer’s Voice" (after [ZULT90]) 


[ZULT90] has suggested a number of adaptations to Akao's matrix of matrices in 
accounting for the differences between producing software and producing non-software 
products. In particular, he adds a series of matrices (the "Z" series) that account for 
hierarchies and differing perspectives of software stakeholders. The deployment of 
concerns and viewpoints of the many different types of customers involved in software 
development is particularly important and requires its own set of matrices [ZULT92]. 
The software engineer must first understand exactly who all the customers (stakeholders) 
are, what requirements they have, and to what extent. The requirements analyst must 
understand the customer needs at a fundamental level before beginning work on the A-1 
matrix [ZULT92]. Secondly, he replaces the use of "material" in traditional QFD 
matrices for "entity" (data) and replaces "function" in traditional matrices with "process". 
To ensure that the process model (from the data-flow diagram) maps properly to the data 
model (from the entity-relationship diagram) he proposes the Z-2 matrix. Next, he states 
that because software, early in its development, is conceptual in nature and can be 
implemented in many different ways, it is generally not necessary to identify potential 
conflicts between the same artifacts and he thus, discards the traditional "roof of the 
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QFD matrix. If it later proves necessary to perform such a comparison for a particular 
project, he provides a single "roof-like" matrix — the A-3 matrix. He points out that new 
concepts and technology are important ways in which software can exceed customer's 
expectations and provides the "E" series of matrices to track potential innovation. The 
"D" series provides a balance between new technology and risk associated with failure 
modes. Akao's B, C, F, and G series matrices may also be adapted to SQFD. 

Just as before, this more complex set of deployment matrices can also be 
diagramed as a software development process diagram, where each step (edge) is labeled 
with the corresponding QFD matrix (see Figure 14). 



Figure 14 SQFD — Matrix Deployment as a Process Diagram 

Another tailoring of Akao's matrices is performed by [THAC90]. Here 
the tailoring is designed to account for the planning phases related to the design of 
embedded software systems (see Figure 15). 
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Figure 15 SQFD for Embedded Systems (after [THAC90]) 


One of the unique aspeets of this adaptation is the establishment of a Teehnology 
Assessment matrix to provide the ability for companies to analyze the difference between 
advanced research and product development. Often, a project that began as a research 
demonstrator or advanced technology prototype becomes the basis for a proposed 
deliverable product. Unfortunately, the tools needed to actually build the product using 
the advanced technology do not exist. The Technology Assessment matrix provides a 
critical test of the viability of the high-level design to ensure that the methods, tools and 
procedures needed to implement the technology actually exist in the company. If they do 
not, then it is possible to return to the architectural portion of the design and rework the 
necessary components [THAC90]. This set of adapted matrices can also be viewed as a 
software development process diagram (see Figure 16). 



Figure 16 Embedded System SQFD Displayed as a Development Process Model 


QFD is often used to implement concurrent engineering, so that parallel portions of the 

design can be worked on simultaneously. [THAC90] has further adapted a set of 

deployment matrices for this purpose, where the deployment matrices are used to deliver 
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key information needed to make a management deeision as to whether to proeeed with 
the development effort or not (see Figure 17). 
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Figure 17 SQFD and Concurrent Engineering (after [THAC90]) 


What all these various efforts demonstrate is that adapting the QFD 
proeess to work with software is possible but requires unique adaptations based on eaeh 
different development effort used. Thus, as the FIFSE seeks to embed QFD within its 
framework, it will do so in a flexible manner, ensuring that the engineer is able to modify 
the set of deployments and the entities being linked in the deployments to the engineer's 
speeifie project and the engineer's specific software development process. 
f. Establishing Correlations 

As QFD matrices are formed and linked, one of the key activities becomes 
establishing the correlation be between entities — correlating the "Whats" to the "Flows." 
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The use of traditional Japanese symbols is typieal in many QFD software packages 
[COHE95][LIUX00][AKAO90]. [ZULT90, 92] also provides a visual means that 
intuitively demonstrates the strength of a correlation between two entities. In most cases, 
these symbols can be typically translated into numerical values of correlation between 0 
and 9. 


Degree of Correlation 
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Figure 18 Typical QFD Symbols for Degree of Relationship 

Using weight ratios of 1:3:9 helps to highlight the relative importance of software 
artifacts making interrelations more obvious, even in complex system development 
[THAC90]. However, as [ZULT92] states, the use of just 1:3:9 limits the accuracy of 
correlation at the source of input and that additional values (5 and 7) can be used. The 
engineer has the option of even using finer distinctions if they feel that consistent 
correlation judgments can be made with precision. [AKAO90] states: 

The most troublesome work in quality chart preparation is correlating the 
demanded quality with quality characteristics [correlating the "Whats" to 
the "Hows"]. Often, this correlation is based on experience, intuition, and 
determination... This correlation should be based, however, on knowing 
and controlling facts. That is, the relationships and their relative strengths 
should be based on factual data and statistical analysis... reliance on 
experience, intuition, and determination may be necessary if some or all of 
the data needed as a basis for confirming the correlating relationships is 
not available when the quality chart is being prepared. In such cases, we 
recommend devising some method to differentiate relationships based 
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solely on experience, intuition, and determination from those based on 
facts. 

[COHE95] asserts that there is no scientific basis for any particular choice of correlation 
values and that QFD practitioners select the particular scheme that over time has proven 
to provide them the best separation of important data from noisy data in their application. 

When establishing correlation between two entities in a QFD matrix using 
a 1:3:9 scheme, there are several notes of caution. First, such a scheme assumes a 
monotonically increasing linear relationship between the two entities. There may, 
however, be instances where this does not accurately model the relationship. As an 
example, recall Kano's model of customer satisfaction and requirements (Figure 9); in 
that model the relationship between customer satisfaction and any particular requirement 
was first dependent on what type of requirement was being considered (thus a 
discontinuous relationship) and second was non-linear in cases of "exciting" or 
"expected" requirements. Finally, the relationship was negative in the case of "expected" 
requirements (not monotonically increasing). So, how do QFD practitioners handle such 
complex relationships? In some cases negative correlations have been used in the QFD 
matrix when a negative relationship exists; but such techniques are often overly 
complicated and the effort in attaining such precision is often not repaid when the results 
are presented. The predominate way of handling complex relationships is to attempt to 
express all entities in such a way that only positive relationships exist, then to make a 
linear approximation of the relationship and finally to take note of the approximation 
when latter viewing the results of the matrix [COHE95]. 

In establishing correlations within the HFSE, the framework will seek to 
remain flexible in allowing the engineer to use whatever values he deems necessary. The 
use of positive numerical values will be the norm, as well as an assumption that only 
positive, linear relationships exist between entities to be correlated. 

g, QFD in Large Complex Software Systems 

The next issue in embedding QFD into the HFSE is related to scalability, 
to determine if QFD can be used in large systems with significant complexity. 
[DEAN92] states that "Complexity has two components: the complexity of the system 

and the the [sic] complexity of the system to bring forth the system." In other words, the 
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issue is whether QFD ean help to manage the eomplexity of large systems and/or 
manage the eomplexity in the development efforts for large systems. Previous work 
indieates that QFD provides positive benefits in both areas. In large system design it is 
useful to map the eustomer driven quality eharaeteristies against sub-systems of the 
design. [DEAN92] proposes doing this by using three dimensions of QFD matrix 
interaetion as shown in Figure 19. 




Figure 19 3D View of Matrix Interaction (after [DEAN92]) 

In this scheme a substitution to account for large systems of systems is to use 
"subsystem" rather than "part" and to then allocate functions (requirements) to the 
subsystems. By using deployments to subsystems in large designs, the developers are 
able to more easily manage the overall complexity of the design. In such cases it is 
typical to develop matrices in which the interactions between subsystems are defined and 
correlated. 

In addressing the complexity of the development effort itself, QFD can 
help in assisting with managing the conflicting interests of both customers and 
developers. In managing customer interests [DEAN92] states that: "Because a large 
system with NASA has many customers, often with conflicting desires, we found the 
need to value each customer with respect to the need for the project to satisfy their 
desires. This quantifies customer political power." In managing the conflicting interests 
of the many developers (with a wide range of expertise) in large system development it is 
often better to have generalists (rather than specialists) at the architectural portions of the 
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QFD interaction. By decentralizing and decomposing the system into meaningful 
subsystems (with low interaction) it is possible for the specialists then to bring the 
expertise fully to bear on the problem. "Fortunately, the geometric nature of QFD is a 
natural medium in which to perform that decomposition and manage the interaction" 
[DEAN92]. 

h. The Role of QFD in this Research 

As illustrated above, the use of QFD in software engineering has the 
potential to provide many significant benefits if properly integrated with a software 
evolution model. Certainly, this integration is one of the central goals of establishing the 
HFSE. The specific use of QED in the HESE can be summarized as follows: 

(1) Relationship Tracking. The matrix structure of QED 
readily lends itself to establishing traceability of relationships between software 
development artifacts. The entities tracked in QED matrices (the "whats" and the 
"hows") become software artifacts. The correlation matrix becomes the mechanism by 
which the relationship (and the strength of that relationship) is established and tracked. 

(2) Dependency Deployment. While the automated deployment 
of different kinds of QED dependencies (different than quality) has been theorized 
[ZUET93], there has not yet been any formal work in establishing automated 
mechanisms to make this a reality. The HESE does exactly that — it provides a formal 
description of automated mechanisms that allow software engineers to define specific 
software dependencies that can then be deployed throughout a software development 
effort. The engineer then has the ability to select particular views of these dependencies 
that provide useful decision support information. 

(3) Adaptable Matrix Deployment. The many permutations 
and adaptations to Akao's matrix of matrices dictate that the HESE must provide a 
flexible method of allowing an engineer to define their own software development 
process and their own artifacts. Trying to define a single "one size fits all" set of matrices 
and artifacts will not properly account for the reality of the many different processes that 
are used to build software. Additionally, the ability to map a set of matrices to a software 
development process and vice versa (recall Eigure 11 / Eigure 12 and Eigure 13 / Eigure 
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14) provides a convenient mechanism for abstracting the key underlying relationships 
represented by the QFD matrices. 

(4) Data Linkage. Lessons from previous research indicate 
that automation is necessary to allow engineers to "browse" through connected design 
information. The underlying hypergraph structure of the HFSE provides the mechanisms 
by which this is possible. By linking all the software design data through QFD matrices 
and then extracting a subset of those matrices will allow the HFSE to provide the 
engineer useful decision support information. 

(5) Cross Communication and Coherency of Design. 

Embedding QED into the HESE will build a framework that enables better cross 

communication between departments in software development process. 

4, Methods for Establishing Interoperability of Software Development 
Models and Tools 

Young points out that consistent representation of the same real world 
entity in various legacy software products is a continual problem for system 
interoperability [YOUNG 1, 02a, 02b]. To address this problem, he presents an Object- 
Oriented Model for Interoperability (OOMl). This model is used to solve the data and 
operational inconsistency problems in legacy systems. The model calls for the 
establishment of a Eederation Interoperability Object Model (ElOM) that is specified for 
a specific group of systems (termed a federation) designated for interoperation. 
[YOUNG 1] states: 

The ElOM consists of a number of Eederation Entities (EEs) that contain 
the data and operations to be shared between systems. The ElOM also 
captures the translations required to resolve differences in representation 
of this data and operations. 

An example of an ElOM for a ground combat vehicle is shown in Eigure 20. 


60 



Federation Interoperability Object Model (FIOM) 


«Federation Entity» «Federation Entity» 





Generalization 


Aggregation 


Figure 20 Federation Interoperability Object Model (from [YOUN02a]) 


At runtime, the OOMI uses a wrapper-based translator to proeess the information 
eontained in the FIOM. The translator automatieally eonverts instances of real-world 
entity attributes and operations to the proper representation to enable interoperation 
between systems. These translations can then be embedded in middleware between 
target systems as shown in Figure 21. 
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Figure 21 Middleware Based Translation Using the FIOM (from [YOUN02b]) 


In addition to defining the constructs of the OOMI, Young provides a 
specialized toolset used to create the FIOM prior to run-time. This tool set is called the 
Object Oriented Model for Interoperability Integrated Development Environment (OOMI 
IDE) and is used to accomplish the following: 

• Discover the information and operations shared between federation 
components, 

• Provide assistance in identifying the different representations used for 
such information and operations by component systems, 

• Define the transformations required to translate between different 
representations, and 

• Generate system-specific information used to resolve representational 
differences between component systems. 

Young's entire Object-Oriented Model for Interoperability is useful to the 
dissertation because it provides a mechanism for establishing the interoperability of 
heterogeneous software development tools and models. The only requirement for these 
models and tools is that they be definable within an object paradigm. 
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Young identifies two eoneepts that are direetly applicable to mapping 
multiple software engineering tools to each other within the HFSE; heterogeneity of 
scope and heterogeneity of representation. Heterogeneity of scope refers to the fact that 
differing amounts and types of information can be specified by different systems to 
represent the state and behavior of the same entity. Heterogeneity of representation refers 
to the fact that different systems, when referring to the same entity, often have differences 
in terminology used, format, accuracy, range of values allowed, and structural 
representation of the included state and behavioral information. 

Within the HFSE, attempting to translate behavioral information is 
particularly challenging. Young points out that "behavioral information can be captured 
in terms of a set of conditions an element must satisfy or as a set of equations describing 
the dynamic behavior of the entity" [YOETNOl]. Another challenge resolved by the 
HFSE using Young's methodology was how to resolve different levels of abstraction for 
information provided in different tools and models. The Federation Entity View (FEV) 
in Young's OOMI provides the ability to resolve these differences: "The FEV contains 
the translations required to convert between each component system representation and 
the 'standard' representation of that view. These translations are used to resolve 
differences in physical representation, accuracy tolerances, range of values allowed, and 
terminology used in representing a federation entity view. These translations are defined 
by the interoperability engineer and stored in the FEV for subsequent use" [YOETNOl]. 

Another challenge relates to communication within the FIOM. Young 
assumes a publish/subscribe mechanism that assumes a one-directional broadcast of 
information from either information sources or information consumers. Updates are a 
new issue in the context of software development environments - more than one node 
(designer, stakeholder, etc.) can propose modifications to the same real world object 
(design component refinement, etc). This may need more sophisticated methods to 
maintain consistence. 

5. Application of Ontologies for Interoperability 
a. Ontology Overview and Example 

The term “Ontology” is borrowed from philosophy where it is defined as a 

systematic investigation of "Existence". The term is now widely used in Artificial 
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Intelligence and Knowledge Engineering where what "exists" are those entities which can 
be "represented." Ontology is the term used to refer to the shared understanding of some 
domain of interest that may be used as a unifying framework to solve problems in that 
domain [USCH96]. An ontology necessarily entails or embodies a world view with 
respect to a given domain. This world view is often conceived as a set of concepts (e.g. 
entities, attributes, processes) along with their definitions and their inter-relationships. 
Because people, organizations, and software systems must communicate between and 
among themselves, there are often difficulties/inaccuracies in communications because of 
differing contexts, understandings, viewpoints and assumptions. Therefore, ontologies 
help to accomplish the following: 

• Improve poor communication, 

• Establish a unifying framework for conceptual models and ideas, 

• Establish the basis for interoperability, and 

• Prevent redundant work and cross purposes. 

[GRUB95] defines an ontology more formally as "an explicit specification of a 
conceptualization" where a conceptualization is "an abstract, simplified view of the world 
that we wish to represent for some purpose" and consists of "objects, concepts, and other 
entities that are assumed to exist in some area of interest and the relationships that hold 
among them." The widespread use of ontologies provides meaningful mechanisms for 
distinguishing various types of objects (concrete and abstract, existent and non-existent, 
real and ideal, independent and dependent) and their ties (relations, dependences and 
logic). Another formal definition is offered by Sowa [SOWAOO] as quoted by [LENCOl] 
who states that an ontology is: 

a catalogue of the type of things that are assumed to exist in a domain of 
interest D, from the perspective of a person who uses a language L for the 
purpose of talking about D. 

[EENCOl] adds: 

Erom a semantic point of view, an ontology determines the domain of 
discourse for a language L, i.e. what L talks about. The ontology on which 
L is interpreted actually constrains the expressiveness of L itself. Eor 
instance, if the ontology only contains plants and animals, then it will be 
impossible to speak about computers, unless they are categorized either as 
plants or as animals, thereby losing the possibility to account for crucial 
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differences among them. To be able to do this, the ontology should be 
refined by adding a further category, e.g. the one of artifactual [sic] 
objects. 

Ontologies reduce or eliminate conceptual and terminological confusion. 
They establish a shared understanding and unifying framework which improves 
communication, consistency and ambiguity, integration of differing perspectives, 
interoperability, and systems engineering [USCH96]. 

(1) Communication. Ontologies help to improve 
communication between people with different needs and viewpoints arising from 
differing contexts. Examples include normative models that establish the semantics of 
the system and potential extensions as well as networks of relationships that explore the 
relationships between entities. 

(2) Consistency and Ambiguity. Depending on the level of 
formality used in its establishment, an ontology provides explicit definitions within the 
domain, eliminating ambiguity and providing consistent interpretation across the domain. 

(3) Integration of Differing Perspectives. Ontologies provide a 
framework for integrating different user perspectives. Often the commonalities in the 
differing user perspectives can form the groundwork for development of standards within 
the community. The differences in the perspectives often lead to different ways of 
categorizing information within the ontology (e.g. in an ontology about plants, with 
differing perspectives of farmers and florists, different sets of information about each 
plant would be needed to support both perspectives). 

(4) Interoperability. Interoperability among systems is 
achieved by translating between different modeling methods, paradigms, languages, and 
software tools. Examples include the following: 

• Integration environment for tools, 

• Inter-lingua translators, 

• Internal interoperability: integration of systems (perhaps legacy 

systems), and 

• External interoperability: insulation of the organization from the 
outside world. 
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(5) System Engineering. Ontologies support improvements in 
system engineering (e.g. reuse, reliability, speeifieation). Examples inelude the 
following; 

• Speeifieation. Ontologies provide a shared understanding that 
assists in establishing the speeifieations of systems and prevents 
later misinterpretation of those speeifieations. 

• Reliability. Ontologies ean form the basis for manual and 
automated verifieation. Eormal ontologies ean be used to make 
assumptions explieit to users. 

• Reusability. Common and explieit understanding allows modules 
to be imported and exported between systems. 

The formalism used in speeifying ontologies varies widely. Ontologies 
ean range from being very informal to very formal [USCH96]. Consider the following 
formalisms: 

• Highly Informal; loosely expressed in natural language, 

• Semi-Informal; expressed in restrieted and struetured form a 
natural language, 

• Semi-Eormal; expressed in an artifieial formally defined language, 
and 

• Rigorously Eormal: metieulously defined terms with formal 
semanties, theorems and proofs of sueh properties as soundness 
and eompleteness. 

As an example of an ontology, the Enterprise Ontology [USCH98] was 
developed within the Enterprise Projeet (a eollaborative effort between the Artifieial 
Intelligenee Applieations Institute (AIAI) at the University of Edinburgh, IBM, Lloyd's 
Register, Logiea UK Limited, and Unilever). The Enterprise Ontology provides a 
framework for enterprise business modeling and is presented as a eolleetion of terms and 
definitions relevant to business enterprises. [USCH98] uses natural language definitions 
for all the terms and is an example of a semi-informal ontology. Table 3 lists the terms 
defined in the Enterprise Ontology. 
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Major Category 

Ontology Terms 

Activity 

Activity, Activity Specification, Execute, Executed Activity 
Specification, T-Begin, T-End, Pre-Condition, Effect, Doer, 
Sub-Activity, Authority, Activity Owner, Event, Plan, Sub- 
Plan, Planning, Process Specification, Capability, Skill, 
Resource, Resource Allocation, Resource Substitute 

Organization 

Person, Machine, Corporation, Partnership, Partner, Eegal 
Entity, Organizational Unit, Manage, Delegate, Management 
Eink, Eegal Ownership, Non-Eegal Ownership, Ownership, 
Owner, Asset, Stakeholder, Employment Contract, Share, 
Share Holder 

Strategy 

Purpose, Hold Purpose, Intended Purpose, Strategic Purpose, 
Objective, Vision, Mission, Goal, Help Achieve, Strategy, 
Strategic Planning, Strategic Action, Decision, Assumption, 
Critical Assumption, Non-Critical Assumption, Influence 
Eactor, Critical Influence Eactor, Non-Critical Influence 
Eactor, Critical Success Eactor, Risk 

Marketing 

Sale, Potential Sale, Eor Sale, Sale Offer, Vendor, Actual 
Customer, Potential Customer, Customer, Reseller, Product, 
Asking Price, Sale Price, Market, Segmentation Variable, 
Market Segment, Market Research, Brand, Image, Eeature, 
Need, Market Need, Promotion, Competitor 

Time 

Time Line, Time Interval, Time Point 


Table 3 Overview of the Enterprise Ontology (after [USCH98]), 


The table illustrates a collection of terms and definitions relevant to business enterprises. 
This collection is presented in natural language and is classified into major categories. 
An example of the definition of the term "Corporation" under the major category of 
"Organization" is as follows [USCH98]; 

CORPORATION: a group of PERSONS recognised in law as having 
existence, rights, and duties distinct from those of the individual 
PERSONS who from time to time comprise the group. 

Notes: 

1. Historically, in law, rights and duties apply to individual 
humans; rights and duties of groups are inherited from this. 

Note that the definition of CORPORATION uses other terms from the ontology (i.e. 
PERSON) and thus establishes a relationship between these two terms. The definition 
also includes additional annotations (notes) that further clarify the definition, reducing 
ambiguity. 
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Ontologies play an important role in the interoperability aspeets of the 
HFSE and the eoneepts about ontologies in this seetion lay the foundation for this role. 
As a basis of implementing Young's OOMI, the interoperability engineer must begin with 
an ontology of the domain. [YOUNOlb] illustrates this essential role in FIOM 
Construetion Use Case in Figure 22. 
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Figure 22 Role of Ontology in FIOM Construction (from [YOUN02b]) 

In the case of the HFSF, the domain is that of software development tools (and artifacts 
produced by those tools). Thus, a first step in establishing the HFSE is to construct an 
ontology for the set of tools to be integrated by the HFSE. The majority of the work in 
establishing this software development tool ontology was undertaken by [HASN03] in 
support of this dissertation. 
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b. Constructing an Ontology 

There is no eurrent field of "ontologieal engineering" comparable to the 
field of knowledge engineering, so there are no standard accepted methodologies for the 
building of an ontology. [USCH96] provides a general methodology for constructing an 
ontology that can be modified and tit to particular purposes and consists of the following 
steps: 

• Identify the purpose and scope of the ontology, 

• Build the ontology, 

• Capturing the ontology, 

• Coding the ontology, 

• Integrating existing ontologies, 

• Evaluate the ontology, and 

• Document the ontology. 

This general methodology consists of four main steps detailed below. 

(1) Identify the Purpose and Scope of the Ontology. One of 
the most important steps in constructing an ontology is to make an early decision as to the 
purpose of the ontology. This purpose provides a controlling perspective on the terms, 
attributes of terms, and relationships captured in the ontology. The scope of the ontology 
provides a guide to the depth and breadth of the intended ontology, consistent with the 
purpose. For instance, if the ontology is to be used for interoperability, then the engineer 
must establish both semantic and syntactic detail (at an appropriate level of detail) in 
order to ensure that information can be transmitted and used between systems. 

(2) Build the Ontology. The first step in building the ontology 
is to capture the key concepts and relationships in the domain and then to precisely and 
unambiguously define these terms. In coding the ontology, the goal is to develop an 
explicit representation of the domain using the concepts and relationships already 
captured. This "coding" can be performed with increasing levels of formality. The 
engineer must decide upon a representation language and must decide upon the meta-data 
that will be used to formally express each ontology term and relationship. Another 
consideration is to decide to what degree (if any) should already existing ontologies be 
integrated into the new ontology. This of course needs to be consistent with the scope of 
the ontology agreed previously. 
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(3) Evaluate the ontology. Speoifie evaluation eriteria for the 
ontology should be established. Sueh eriteria eould be based on the general guidelines 
[GRUB95] provides for eonstructing an ontology. These guidelines inelude elarity, 
eoherenee, extensibility, minimal ontologieal eommitment, and minimal encoding bias. 
The ontology is then iteratively compared to these criteria and refinements are made as 
needed. [GRUN95] offers a more formal approach to the evaluation of ontologies using 
formal competency questions and completeness theorems. His approach requires a 
formal ontology in which the ontology definitions and constraints on their interpretation 
have been defined using first-order logic. 

(4) Document the ontology. The final step is to document the 
ontology. All assumptions about the domain should be annotated as well as information 
about the meta-data used to describe the ontology. Of particular importance is to 
document the ontology boundaries (consistent with the scope). This documentation can 
take the form of textual descriptions, formal predicates, and UML diagrams. 

[NOYNOl] offers a slightly more specific set of steps for constructing an 
ontology; however, her methodology assumes the use of the Protege ontology capture 
tool [PROTOSa]. The seven steps in her methodology include the following: 

• Determine the domain and scope of the ontology (similar to (1) 
above), 

• Consider reusing existing ontologies (as in step (2) above), 

• Enumerate important terms in the ontology (as in step (2) above), 

• Define the classes and the class hierarchy (using Protege), 

• Define the properties of classes — slots (using Protege), 

• Define the facets (types of properties) (using Protege), and 

• Create instances of the classes (using Protege). 

This methodology does not address step (3) (ontology evaluation) of the [ErSCH96] 
methodology; but, it does provide more detail and a specific tool for accomplishing steps 
(2) and (4). 

The general methodology proposed by [USCH96] and the more specific 
methodology by [NOYNOl] are important to this dissertation in that they form the 
template by which a methodology is established for building the software development 
tool ontology upon which the HESE relies. The details of this modified methodology 

(and the results from the effort) are presented in Chapter III. 
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c. Ontology Definition and Capture 

Steps (2) and (4) in the general ontology design methodology above imply 
that some of the key aetivities involved in ontology design eenter around building and 
documenting the ontology. In the case of this dissertation, the tool used for both of these 
steps is an ontology capture tool developed at Stanford University called Protege-2000. 
This tool can be used to define the meta-data, the structure of the information of the 
ontology, as well as to capture specific instances of ontology classes (consistent with that 
structure). 

Protege-2000 is a knowledge-based design and knowledge-acquisition 
system. It is available free from Stanford University's Protege project homepage 
[PROTOSa] and is compatible with a wide range of knowledge representation languages 
[PROTOSb]. The tool allows the ontology designer to create custom knowledge-based 
tools for particular applications. Protege assists software developers in creating and 
maintaining explicit domain models, and in incorporating those models directly into 
program code. The core concept behind the architectural makeup of Protege-2000 is 
ontology design. The tool allows the designer to establish the granularity of the design in 
a domain-specific area. Then using problem-solving methods specific to that domain, 
domain experts can then search the ontology knowledge base. 

The Protege knowledge tool uses four main concepts that are represented 
in the software by frames. These are 

• Classes, 

• Instances, 

• Slots, and 

• Facets. 

Classes represent the definitions of concepts; instances represent the specific examples of 
a concept; and slots represent attributes of either a class or an instance. Finally there are 
facets, which are defined as properties of slots, and are constraints on slot values 
[PROTOSa]. Figure 23 is screen shot of the Protege-2000 knowledge acquisition tool. 
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Figure 23 Protege Screen Shot 

This particular screen shot is taken from the Requisite®Pro Ontology (one of the 
subordinate ontologies of the HFSE presented later in the dissertation). Note the use of a 
class-hierarchy tree in the upper left panel, with slots for the selected class displayed in 
the lower right panel. Protege offers tabs for navigating between classes, slots, forms (to 
collect data), instances, and queries (to collect specific data from the ontology database). 

While Protege with its hierarchical class structure at first looks much the 
same as an object-oriented software approach, there are differences. [MUSE98] and 
[NOYNOl] both point out that ontology development using Protege is different from that 
taken in traditional object-oriented programming. In object-oriented approaches both the 
domain knowledge (the attributes of objects) and the problem solvers (the methods) are 
bundled together. Sending messages from one object to another controls program 
execution. Each object encapsulates both data and the methods that operate on that data. 
In the Protege approach, however, the problem-solving methods are separate entities unto 
themselves and have formal parameters that must be mapped to the appropriate classes in 
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the domain knowledge (i.e. the methods (Protege slots) have an existenee outside of and 
distinet from the elass). 

The Protege tool itself is GUI-based; all the design is done using forms 
and tabs. The tool also employs a visualization tool that allows the designer to see and 
edit the ontology strueture. The Protege API provides designers the ability to add plug¬ 
ins and to aeeess domain knowledge stored in the Protege tool from other applieations. 

The role of Protege in the dissertation is that it is the ontology definition 
and eapture tool that is used to define the software development tool ontology required by 
Young's OOMI for establishing interoperability between heterogeneous software 
development tools. The ontology data-base required by [YOUN02b] (reeall Figure 22) 
is that of Protege. A summary of the HFSE ontology results from Protege are presented 
in Chapter III; however, for a more eomplete and detailed explanation of how Protege 
was used to support this dissertation, see [HASN03]. 

d. UML as an Ontology Description Language 

[CRAN99, 01] and [KOGU02] present the Unified Modeling Language as 
a possible language for defining and deseribing domain ontologies. Object-Oriented 
Modeling (OOM) and the Unified Modeling Language (UML) have established a 
significant following in the field of software engineering. Because of this acceptance and 
the fact that OOM and UML are widely supported by robust commercial tools, the use of 
UML for ontology representation is attractive. [KOGU02] offers the following additional 
reasons why an ontology designer should consider UML as a representation language for 
ontologies: 

• UML is graphical and easily understood. 

• UML is an open standard managed by the OMG. 

• UML has standard mechanisms for defining extensions. 

• Real world systems often have existing UML models. 

[CRAN99] points out that UML by itself is often not expressive enough to explicitly 
define ontology terms and constraints. He points to the use of the Object Constraint 
Language (OCL) in refining relationships on and between classes as a way of 
overcoming this shortcoming. 
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Because Young's interoperability model is highly reliant on an object 
structure within the FIOM, the use of UML to define the relationships between ontologies 
in the HFSE makes sense. The OOMI methodology uses a UML type structure to 
express the inter-relationships between objects in different ontologies - mirroring that 
implementation will make it easier to apply Young's methodology [YOUN02b]. 

C. RELATED WORK 

The foundations for the contributions of this dissertation were laid in the previous 
section. In this section, the focus is on identifying the related work by others (that work 
which attempts to achieve a similar purpose as the HFSE). This section identifies and 
distinguishes how this related work differs from that accomplished by this dissertation. 

1. Software Development Tool Suites: The Rational Approach 

While there are many software development tool suites, perhaps the most 
significant work to date in developing a large integrated set of powerful tools for building 
software has been undertaken by Rational Software Corporation. 
a. Summary 

[KRUC96] provides an overview of the Rational Development Process. 
He describes the Rational Development Process for software as a highly automated, 
object-oriented, iterative and incremental software development process. It is centered 
around three main pillars; people, process, and tools/methods. The process can be 
approached from two main perspectives: management and technical. Prom the 
management perspective there are four main phases of development: inception, 
elaboration, construction, and transition. Prom the technical perspective, development is 
best viewed as a series of incremental iterations concluding with the release of a product. 
The two perspectives synchronize through the production of artifacts related to 
development as illustrated in Pigure 24 below. 
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Figure 24 Synchronization of Perspectives in the Rational Process (from [KRUC96]) 


The Rational process identifies a number of artifacts; however, the software itself is not 
considered an artifact. These artifacts include the following: 

• Management artifacts: organizational policy, vision, business case, 
development plan, evaluation criteria, release description, 
deployment document, status assessment; and 

• Technical artifacts: user's manual, software documentation, 
software architecture 

Intellectual activity (such as planning, analysis, design, etc.) can be done 
in any phase. Figure 25 gives an example of the amount of intellectual activity that might 
take place during any particular phase. 
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Figure 25 Intellectual Activity in the Rational Process (from [RATIOS]) 

While continually growing, the Rational's tool support for software 
development is substantial. [RATI98] points out that any software engineering process 
requires tools to support development activities throughout the software's lifecycle: 

An iterative development process puts special requirements on the tool set 
you use, such as better integration among tools and round-trip engineering 
between models and code. You also need tools to keep track of changes, to 
support requirements traceability, to automate documentation, as well as 
tools to automate tests to facilitate regression test. The Rational Unified 
Process can be used with a variety of tools, either from Rational or other 
vendors. However, Rational provides many well-integrated tools that 
efficiently support the Rational Unified Process. 

The following are the automated tools available from the Rational suite to 
support software development: 

• Rational Requisite®Pro — a requirements engineering tool that 
makes requirements easy to write, communicate and change. 

• Rational ClearQnest^M — a change-request management product 
that enables project teams to track and manage all change 
activities. 

• Rational Rose® — a visual modeling tool for business process 
modeling, requirements analysis, and component architecture 
design. 


Phases 


Inception 

Elaboration 

Construction 

Transition 



' t —— 


Initial 

Elab #1 

Bab #2 

Const 

1 Const 

Const 

Tran 

Iran 





Lf2 

#N 

#1 

«2 



Iterations 


76 






















































• Rational SoDA® — automates the produetion of doeumentation 
for the entire software development proeess. 

• Rational Purify® — a run-time error eheeking tool for applieation 
and eomponent software developers programming in C/C++. 

• Rational Visual Quantify^M — a performanee profiling tool for 
applieation and eomponent software developers programming in 
C++, Visual Basie, and Java. 

• Rational Visual PureCoverage^''* — identifies areas of eode not 
exereised in testing so developers ean thoroughly, effieiently and 
effeetively test their applieations. 

• Rational TeamTest — ereates, maintains and exeeutes automated 
funetional tests, allowing the test team to thoroughly test the eode 
and determine if the software meets requirements and performs as 
expected. 

• Rational PerformanceStudio^''* — a tool that measures and 
predicts the performance of client/server and Web systems. 

• Rational ClearCase® — a software configuration management 
tool. 

These tools have been specifically designed to be interoperable and to function by using a 
"model" approach. The idea is that a model of the software system is created and specific 
artifacts related to the model are produced by the tools. 

b. Relationship to the Dissertation Topic 

There are several concepts from Rational's integrated tools suite that are 
related to work presented in this dissertation. 

(1) Management and Technical Perspectives. The Rational 
Development Process has both management and technical perspectives, as does the 
HFSE. These perspectives allow particular stakeholders to glean particular information 
from the development effort subject to their needs. 

(2) Process Dependence. The Rational Development Process 
ties together people and tools through process (and procedures and artifacts). The tools 
supplied by Rational are integral to the Rational Unified Process. The HFSE, on the 
other hand, ties together tools for people, independent of process. 

(3) Diversity of Artifacts. The diversity and number of 
management and technical artifacts imply a need for life cycle coverage. Because the 
suite is managed and maintained by a large software developer with a significant user 
base, artifacts developed today will likely be able to be viewed decades later (as long as 
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Rational remains in business). This may not neeessary be the ease in the HFSE, where 
artifaets developed with tools that the user has today may not be available (beeause of 
software/hardware obsoleseenee) deeades later. This presents an issue that tests long¬ 
term openness/extensibility of the HFSE and is an issue to be eonsidered in future 
researeh. 

c. Weaknesses 

The main weakness of Rational's tool suite is one of "Eegaey System 
Interoperability." Rational Software Corporation's history is one of software 
development tool aequisition — eolleeting the "killer apps" of the software development 
domain. Rational then lashed together these tools and developed a "unified" proeess 
around the tools rather than define the proeess, then develop tools that support that 
proeess. This is not to say that what they have aeeomplished is not without merit. In 
faet, the popularity of Rational's tool suite speaks volumes about its usefulness to produee 
real software produets. However, in the ideal world, proeess should eome first, with tools 
speeifieally designed and tailored to support the proeess — not the other way around. 
Otherwise, important aspeets of the proeess eould be left out or forgotten simply beeause 
they were not supported by the tools available. 

The main advantage of the approaeh taken with development of the HFSE 
over the Rational tool approaeh is that the HFSE is speeifieally designed to aeeount for 
legaey software development tools and proeesses. Software engineers eonstruet the 
HFSE around their already existing software development proeess and tools. The HFSE 
allows software designers to interoperate between the tools that they already use rather 
than have to rely on tailoring an integrated tool suite to their use. They will be able to use 
the proeess they want with the tools they want — building up their development 
environment over time. 

2, Rational Unified Process (RUP) 

As in the ease of software development tool suites, there are numerous software 
development proeess models that provide software engineers methodologies for 
produeing software. To some degree, eaeh of these proeess models attempts to provide 
some of the same aims as the HFSE; namely, providing software engineers an ability to 

have life-time visibility and leverage of all the software development artifaets produeed. 
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These proeess models include the waterfall model, the linear sequential model, the 
prototyping model, the rapid application development model, the evolutionary model, the 
spiral model, the Win-Win model, formal methods, etc. A good survey of each of these 
process models in provided in [PRESOl] and [SOMMOl]. Rather than attempt to 
compare each of these models against the HFSE, the focus of this section will be to 
examine just one process model (Rational's Elnified Process (REIP)) and contrast it 
against the HFSE approach. 

a. Summary 

[RATI98] is a guide to using the Rational Einified Process® and was 
produced by Rational Software Corporation to provide software developers a set of six 
best practices to employ when using the process. [RATI98] begins with a summary of 
the RUP; 

The Rational Unified Process® is a Software Engineering Process. It 
provides a disciplined approach to assigning tasks and responsibilities 
within a development organization. Its goal is to ensure the production of 
high-quality software that meets the needs of its end-users, within a 
predictable schedule and budget... The Rational Unified Process is a 
process product, developed and maintained by Rational® Software... The 
Rational Unified Process enhances team productivity, by providing every 
team member with easy access to a knowledge base with guidelines, 
templates and tool mentors for all critical development activities... The 
Rational Unified Process activities create and maintain models. Rather 
than focusing on the production of large amount of paper documents, the 
Unified Process emphasizes the development and maintenance of 
models —semantically rich representations of the software system under 
development...The Rational Unified Process is supported by tools, which 
automate large parts of the process. They are used to create and maintain 
the various artifacts — models in particular — of the software engineering 
process: visual modeling, programming, testing, etc. They are invaluable 
in supporting all the bookkeeping associated with the change management 
as well as the configuration management that accompanies each 
iteration... The Rational Unified Process is a configurable process. No 
single process is suitable for all software development. The Unified 
Process fits small development teams as well as large development 
organizations. The Unified Process is founded on a simple and clear 
process architecture that provides commonality across a family of 
processes. 


79 



The RUP provides a great deal of automation for many aspeets of software 
development. The RUP relies on unifying proeess, people, and tools into a management 
and teehnieal perspeetive as shown in Figure 26 [KRUC96]. 



Technical Perspective 


Figure 26 Rational Unified Process (from [KRUC96]) 


In addition to providing an overview of the RUP, [RATI98] identifies and 
deseribes six best praetiees to employ when using the RUP. 

(1) Develop software iteratively. Apply an approaeh that 
takes advantage of an inereasing understanding of the problem during iterative 
refinements. 

(2) Manage requirements. Elieit, organize, and doeument the 
system's required funetionality and eonstraints. Doeument design deeisions and 
tradeoffs. 

(3) Use Component-Based Arehiteetures. Establish an early 
baseline arehiteeture that is flexible, understandable, and promotes software reuse. 

(4) Visually Model Software. Capture the strueture and 
behavior of arehiteetures and eomponents while hiding their details. Use graphieal 
building bloeks and abstraetion to eonvey main ideas. 

(5) Verify Software Quality. Review the software with respeet 
to the requirements. Cheek reliability, funetionality, applieation performanee, and system 
performanee. 

(6) Control Changes to Software. Change is inevitable. The 
sueeessful projeet requires that you eontrol, traek, and monitor ehanges. 
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b. Applicability or Relationship of Work to the Dissertation Topic 

There are two eoneepts assoeiated with the RUP that are similar to the 
approaeh taken by the HFSE. 

(1) The idea that the Rational Proeess is configurable is 
noteworthy. The HFSE is configurable as well; however, as Rational provides a suite of 
tools where a software development organization "turns-off' that functionality which it 
does not use or is not applicable; users of the HFSE will "build-up" their configuration by 
adding only those tools which are useful. 

(2) Rational uses Tool Mentors to provide users a step-by-step 
guide describing in detail how to operate a tool, (i.e. what menus to launch, what 
information to enter into dialog boxes, and how to navigate a tool) to carry out an activity 
within the process. The Mentors allow users to link the tool-independent process to the 
actual manipulation of the tools. The main idea here useful to the dissertation is that 
Rational still requires the software engineer to be the primary linkage between tools. The 
tools themselves contain some compatible file formats and processes, they allow cut and 
pasting between tools, but there is not an automated linkage between all relevant objects 
between all the tools. 

c. Weaknesses 

The Rational Unified Process differs from the HFSE approach in the 
following four significant ways: 

• Over-reliance on people and process as unifying factors, 

• Use of only specific proprietary tools, 

• Configurability of the tool set, and 

• Eack of a QFD style dependency metric that links artifacts in all 
phases of software development. 

While the Rational development process unifies specific tools through 
people and process (and procedures and artifacts), the HFSE unifies any tools fm people, 
independent of process. In other words, the Rational process is overly reliant on people 
and process to be the unifying factor between their specific set of tools. The HFSE is not 
dependent on any specific set of tools and instead will allow the developers to unify the 
tools with which they are most familiar. Users of the HFSE will "build-up" their 
configuration by adding only those tools which are useful. In other words, the Rational 


81 



Process is configurable only as long as software engineering is restricted to subsets of the 
tools provided by Rational (and a few Microsoft office tools for which they have 
accounted); while, the HFSE will accommodate an open universe, including tools that 
have not been developed yet. Finally, the Rational approach does not provide for the 
QFD style of holistic linkage of all artifacts created in the software development process, 
hacking this linkage, it is impossible to gain adequate visibility of the effects of particular 
metrics on other phases of the development process. 

3, Integrated Software Development Environments 

There has been a significant amount of software engineering research associated 
with Integrated Software Development Environments (ISDEs), Integrated Project 
Support Environments (IPSEs), and Integrated CASE tools (I-CASE). This includes a 
workshop series (ACM SIGSOFT's Software Engineering Symposium on Practical 
Software Development Environments (SESPSDE) over a 5 year period in the late 1980’s 
and early 1990's) as well as a major DARPA program (called Arcadia). This previous 
work differs from the HFSE primarily in that the HFSE focuses on the holistic nature 
software artifacts and the relationships between them (captured by QFD) whereas these 
other previous efforts focused mainly on electronic syntactic data interoperability 
between tools. These previous efforts cast the HFSE as unique in terms of 
interoperability, but not particularly original. However, the integration of QFD into the 
RH model to provide rich dependency relationships between development artifacts 
remains both unique and original. 

a. ISDEs and ISPEs 

[BROW92, 93] examines and summarizes some of the problems in 
developing ISDE/ISPE technology. He points out that the research associated with 
software development tool support has centered around two main approaches. 

(1) IPSE Approach. In this approach, the IPSE developer 
attempts to provide an infrastructure for common services required by multiple tools. 
The environment is often constructed around a particular software development process 
and provides specific services in support of that process. [BROW93] states: “The 
majority of the work in this area has explored the common services that need to be 
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provided by such a framework, and the consequent interaction between the framework 
and the tools which are embedded within it.” 

(2) Computer-Aided Software Engineering (CASE) Tool 
Approach. In this approach, market needs and customer feedback drive the expansion of 
existing CASE tools to encompass ever-greater functionality and provide additional 
features to support ever-increasing portions of the software development process. 

It is the IPSE approach that most closely parallels the approach in the 
HESE, so it is useful to examine why the IPSE approach has yet to meet expectations for 
improving software development. [BROW93] cites a number of reasons. Eirst, there is 
little economic evidence that IPSE approaches are effective and without such evidence 
developers are reluctant to adopt such technology. Developers would much rather 
purchase individual CASE tools and glue them together. [BROW93] states: 

...the purchase of a CASE tools is not seen as a strategic decision, but 
more as a pragmatic one. Eor example, it is often found to be easer to 
obtain money and management support for purchasing a new CASE tool, 
or integrating a set of CASES tools, than for investing in IPSE technology. 

This is due to the incremental nature of the investment, the more visible 
improvements in productivity they often bring, and the more manageable 
complexity of the new software. 

Second, IPSEs’ size and complexity makes them unmanageable; often there is a 
perception that productivity will actually decrease because of this complexity. Third, the 
lack of flexibility and generality in IPSE approaches makes them less attractive. While 
generality is a goal of most IPSE technologies, few in reality are flexible enough to adapt 
to the way in which developers actually develop software. In other words, most IPSE 
technologies require fundamental process or activity changes on the part of the user 
rather than accommodating what the user already does and provide additional 
functionality in support of their process or activity. Einally, there is concern over long¬ 
term support of IPSE approaches. 

b. Portable Common Tool Environment (PCTE) 

A typical IPSE research initiative is the Portable Common Tool 
Environment (PCTE), which was a project supported by the European Computer 
Manufacturers Association (ECMA) during the late 1980’s and early 1990’s. The project 
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centered on defining a publie tool interfaee for whieh software engineering environments 
were eonstrueted. The PCTE provided a speeifie tool interfaee and eentral Objeet 
Management System (OMS). Software development tools that eomplied with this single 
interfaee would store their development artifaets within the PCTE OMS. Einks (whieh 
eould be speeifieally typed) eould then be established between objeets in the eentral 
PCTE database [BOUD88]. 

In identifying missteps in IPSE researeh, [BROW92] points out that 
interfaee and repository approaehes (sueh as PCTE) are unlikely to be of signifieant 
value. The reason for this is beeause few eommereial software development tool 
developers have substantial eeonomie ineentive to build tools eompliant with sueh an 
interfaee definition and speeifie OMS strueture. 

c. Arcadia 

A DARPA IPSE initiative ealled “Areadia” was initiated in the late 1980’s 
with a goal of performing validated researeh of software development environments. 
Areadia eonsisted of a number of loosely grouped approaehes, eaeh of whieh addressed 
different parts of the IPSE problem [KADI92a, b]. A few of the systems ineluded in the 
Areadia projeet follow: 

• Chiron-1: a user interfaee system [TAYE94], 

• Chimera: a hypertext system for linking heterogeneous systems 
[ANDE94], 

• APPE/A: a software proeess programming language [SUTT95], 

• Pleiades: an IPSE objeet management system [TARR93], and 

• Triton: an IPSE objeet-oriented database management system 

[HEIM92]. 

Areadia used a proeess programming language APPE/A to tie together the many 
threads of an IPSE environment. Mueh of the work has eentered on using and modifying 
database systems for undertaking syntaetie interoperability via the proeess programming 
language. Readers interested in the Areadia projeet are referred to the eolleeted Areadia 
papers in [ARCA95]. 

d. Weaknesses 

The majority of IPSE approaehes have foeused on supplying syntaetie data 
exehange by providing integration environments and eommon serviees for embedded 
tools. As [BROW92] points out, these efforts have met with little sueeess: 
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The bottom line is that eurrent work on IPSEs is foeusing on the wrong 
thing. Instead of ereating meehanisms for integration at the lexieal or 
syntaetie level, it should be addressing how to provide user funetionality, 
produetivity, software quality, and so on - issues that eome from stressing 
semantie- and method-level integration. 

In some eases, eommereial vendors have attempted IPSE implementations by buying 
oolleetions of CASE tools and “gluing” them together “through a eommon set of data 
definitions used between the tools, use of a eommon data transfer protoeol, or through the 
writing of individual eonversion routines to link the tools used by the organization” 
[BROW93]. Unfortunately, these approaehes are not providing substantially new 
funetionality; they are only providing various levels of eleetronie data interoperability. 

The HESE provides a holistie approaeh eentered on the aetual software 
development proeess the developer is using. To date, there has been eomparatively little 
researeh that addresses “proeess-” oriented IPSE approaehes. [BROW93] states: 

There is at least one further view of integration whieh has yet to reeeive 
signifioant attention - a process view. This... approaeh addresses the 
integration of tools with an organization’s exiting software development 
proeess. No generally applieable models are eurrently available in thi s 
area. 

While Areadia was a projeet that attempted to fill a part of this researeh gap through use 
of a dedieated, formal proeess programming language, the HESE is a less formal (but 
more flexible and pragmatie) proeess approaeh that allows the user to model their 
existing proeess graphieally and then to holistieally link artifaets in CASE tools that the 
user is already using with a rieh set of user defined dependeney relationships. Einally, 
the HESE differs from this related IPSE work in that it addresses many of the 
shorteomings of other IPSE approaehes beeause it is relatively light-weight, ean be 
applied inerementally to CASE tools that developers already have (or will purehase in the 
future), and does not require any long-term support. 

4, Software Engineering Ontologies 

There is a great deal of literature related to the use of ontologies for eapturing the 
terminology of a domain for software engineering purposes (i.e. to build software tools to 
support a partieular domain). In faet, the Enterprise Ontology presented earlier is one 
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such example. However, there is very little literature related to the development of 
ontologies that support the domain of software development tools themselves. Two 
exeeptions worth presenting here are work done for the Software Engineering Body of 
Knowledge (SWEBOK) and the DARPA Agent Markup Eanguage (DAME). 

a. Software Engineering Body of Knowledge 

The Software Engineering Body of Knowledge (SWEBOK) is an ongoing 
IEEE projeet devoted to providing a "eonsensually-validated eharaeterization of the 
bounds of the software engineering diseipline" [SWEBOl]. The SWEBOK eategorizes 
the existing (and future) knowledge for the domain of software engineering; however, it 
does not attempt to define that knowledge. The SWEBOK is subdivided into the 
following ten knowledge areas that diseriminate among the important eoneepts of 
software engineering; 

• Software Requirements, 

• Software Design, 

• Software Construetion, 

• Software Testing, 

• Software Maintenanee, 

• Software Configuration Management, 

• Software Engineering Management, 

• Software Engineering Proeess, 

• Software Engineering Tools and Methods, and 

• Software Quality. 

Eaeh of these areas is further subdivided by an established taxonomy. Eor 
instanee, the eategories for Software Requirements are shown in Eigure 27. 
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Figure 27 SWEBOK Software Requirements Taxonomy (after [SWEBOl]) 

Note that the level of detail of the taxonomy is fairly abstraet. Within the SWEBOK are 
textual deseriptions of what each category of knowledge represents; however, these 
definitions are not explicit. 

More germane to the topic of this dissertation is the SWEBOK taxonomy 
associated with software development tools. Eigure 28 provides the complete listing of 
the "Tools" portion of the "Software Engineering Tools and Methods" knowledge area. 
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Figure 28 SWEBOK Software Tool Taxonomy (after [SWEBOl]) 

The SWEBOK software tool taxonomy illustrated in Figure 28 ean be 
considered the beginnings of an informal ontology to describe the domain of software 
development tool knowledge. However, its usefulness as an ontology for establishing 
interoperability between different software tools is extremely limited. In the case of the 
HFSE, the SWEBOK does not provide enough detail to make it possible to use this 
ontology for employing Young's OOMI methodology. 
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b. DARPA Agent Markup Language 

The DARPA Agent Markup Language (DAML) projeet is a relatively 
reeent projeet that is supporting the development of the “Semantie Web” (an improved 
World Wide Web where agents ean understand the meaning of hyperlinked entities) 
[DAML03]. One aim of this DARPA program is to link together many ontologies of 
different domains. In support of this effort, DAML has established an ontology library 
with over 190 different ontologies from a variety of eontributors. 

Two of the ontologies in the library deal speeifieally with software 
development tools and software engineering. The Software Tool ontology in the DAML 
library is an ontology developed to provide summary information about the software 
tools used in a partieular researeh effort. The ontology is relatively small with just four 
elasses and eleven properties. This ontology is summarized in Table 4. 


Ontology 

Purpose 

Summary information regarding software tools used by a researeh 
program. 

Classes in 
the Ontology 

Group, Person, Tool, User 

Properties in 
the Ontology 

Category, deseription, email, howUsed, interfaee, name, priee, site, 
soureeCode, user, uses 


Table 4 DAML Ontology Library: Software Tool Ontology (after [DAML03]) 


The "Software Engineering” ontology from the DAML library is used to 
annotate a UML-based toolset. It is a bit larger with over sixty elasses and one hundred 
properties. An exeerpt from this ontology is presented in Table 5. 
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Ontology 

Purpose 

Used to annotate a description of the UME-Based Ontology Toolset 
project 

Classes in 
the Ontology 

AnnotationTool, Annotator, Architecture, ArtificialAgent, 
Artificialintelligence, ArtificialEanguage, CASEtool, 

CognitiveScience, Component, ComputerScience, DAME, Discipline, 
domainOntology, Engineering, Eeature, feature, EormalEanguage, 
formalmethods, formalverification, ... 

Properties in 
the Ontology 

addsAnnotation, annotates, annotatesWith, appliesSemanticsfrom, 
applyTo, applyTool, conductedin, connects, connectsTo, creates, 
defmedBy, designedBy, designedEor, displaysMessage, distribution, 
elementOf, enablesTool, evaluates, exports, extends, graphicalView, 
implementationEanguage, implementationOf, implements, imports, 
includesElements, integrates, interpret, inventedBy, 
inverseOfaddsAnnotation, inverseOfannotates, inverseOfannotatesWith, 
inverseOfappliesSemanticsfrom, ... 


Table 5 DAML Ontology Library: Software Engineering Ontology (after [DAML03]) 

Of note is that neither of these existing ontologies really addresses the 
domain of interest of this dissertation (Software Development Tool Artifacts). The first 
ontology is only used for collecting summary information about different software 
development tools that a researcher might use, and the second ontology deals with 
annotating one specific UML based software development tool. These ontologies 
provide evidence that previous work has taken place in developing ontologies related to 
the domain of interest; unfortunately, neither ontology satisfies the need for an ontology 
to provide software tool interoperability. 

5. The Uses of QFD for Software 

As previously discussed, the use of QFD in software development has been 
limited to date. However, there are some case studies worth mentioning. [BETT90] 
presents a case study from the PRIMA project at Hewlett-Packard in which an 
abbreviated set of Zultner [ZULT90] matrices are used. That study found that the major 
value added by the use of the QFD matrices was to aid in planning and decision making 
portions of the development effort. [SHAR91] presented an overview of results at IBM 
in which different subsets of Akao's matrices were used and one of the main noted 
benefits was in getting all segments of the development effort to work in a cohesive 
manner in meeting customer requirements. [HRON93] reported a case study from 
Digital's Corporate Telecommunications Software Engineering (CTSE) group that 
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performed a distributed QFD session between Europe and the U.S. using Video- 
Teleeonfereneing. They too, used modified Akao matriees with eomputer support for 
eompleting the tables. 

An interesting approaeh to Objeet-Oriented Analysis (00A) using QFD is 
presented by [LAMI95]. Table 6 below summarizes the matriees reeommended for 
using QFD to identify and quantify the relationships between key artifaets in OOA (an 


entry in the table indieates the use of a partieular matrix). 
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Table 6 QFD Matrices for Performing Object-Oriented Analysis (after [LAMI95]) 


[LAMI95] cautiously proposes a methodology for using QFD to check to 
determine whether the IEEE Quality Eactors (efficiency, integrity, reliability, 
survivability, usability, correctness, maintainability, verifiability, expandability, 
flexibility, interoperability, portability, reusability, etc.) are present in a software design: 

Some practitioners of QED, myself included, are uncomfortable with a 
standardized set of quality factors. It is risky to rely on a list of factors 
that are by necessity very general in nature. Designers and engineers will 
be seduced into believing that they need only consider the "standard 
quality factors" to do all that is necessary to assure that a quality product 
has been developed. The history of QED, if it has shown anything has 
been that successful designs are those with meticulously incorporate the 
voice to the customer as it directly relates to the user's experience with the 
product in actual use. Every attempt of which I am aware to create 
generic QED tables, customer demands, or quality characteristics has been 
a disappointment. The use of generic lists of "-ilities" should be limited to 
verification and completeness checking of distinct quality table that have 
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been eonstrueted aeeording [to] aeeepted QFD praetiees... Looked at 
another way, these "-ilities" represent the "must-be" quality {dissatisfiers 
in Kano's terminology.) From this perspeetive, it is easy to see that this 
analysis, while useful, is insuffieient to assure exeiting quality in a system 
design. 

The signifieant thing to note from these limited case studies is that none have 
taken an approach similar as to the one accomplished by the HFSE. All of the SQFD 
studies surveyed have centered on the use of QFD in the requirements or planning phases 
of the development effort using some subset of already established QFD matrices. None 
have attempted the approach taken in the HFSE to define QED matrices based on already 
existing software development efforts and to integrate these matrices into the software 
evolution model. 


D, CHAPTER SUMMARY 

This chapter presented the results of a comprehensive literature review associated 
with previous work in the dissertation area. The chapter presented foundational work that 
establishes the underpinnings of the dissertation research. The foundational work of this 
dissertation rests largely on these following main research areas and researchers: 

• Software Evolution [EEHM69, 97, 98], 

• Relational Hypergraph Model of Software Evolution [LUQI90] and 
[HARN99a, 99b, 99c], 

• Software Quality Eunction Deployment [ZUET90, 92, 93], 

• Object-Oriented Methodology for Interoperability [YOUNG 1, 02a, 02b], 
and 

• Use of Ontologies in Interoperability [USCH96, 98]. 

The chapter also presented an overview of related work in this area. The 
distinctions between how this related work differs from the work on the HESE were 
highlighted. 
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III. TOWARDS A SOFTWARE DEVELOPMENT TOOL 

ONTOLOGY 

A. CHAPTER OVERVIEW 

The first step in applying Young's OOMI methodology to the domain of software 
development tools is to establish a federation ontology that deseribes the domain and to 
establish specific tool ontologies of the tools to be integrated within the FIOM (and thus 
the HFSE). This effort was specifically undertaken by Hasni [HASN03] in direct support 
of this dissertation. This chapter summarizes that work. Readers interested in additional 
detail of the ontologies developed in support of this dissertation are referred to 
[HASN03]. 

This chapter provides an overview of the methodology used to develop the 
software development tool federation ontology. It summarizes the results of the domain 
analysis undertaken to produce the federation ontology. It presents the details of the 
federation ontology as well as summarizes the two specific tool ontologies. Finally, the 
chapter presents results of how the three ontologies inter-relate by using UML to annotate 
the inter-relationships. It is from these inter-relationships that the OOMI IDE produces 
translators that can be embedded in middleware to actually exchange data and perform 
joint task execution. 

B, METHODOLOGY FOR BUILDING THE ONTOLOGY 

One way to overcome the obstacles posed by lack of interoperability in 
heterogeneous software development is to establish a unifying contextual framework for 
the domain. As this contextual framework or “ontology” emerges; people, 
organizations, and software systems will be able to communicate with more efficiency. 
[USCH96] points out that engineers must often integrate different ontologies in the same 
domain to account for legacy systems. To achieve interoperability between systems with 
different process ontologies, it is first necessary to develop a common ontology 
applicable to all. This is the approach Young takes in establishing a FIOM in the OOMI 
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[YOUN02b] and the approach that will be taken for establishing the object model for the 
HFSE. 

Young's object-oriented methodology for establishing interoperability between 
heterogeneous systems [YOUN02b] allows interaction between the same real-world 
entities, represented differently in different systems. This approach resolves the 
differences that exist between different kinds of systems via an establishment of a FIOM. 
The establishment of such an object federation between existing process models together 
with the integration of the federation with an extended evolution model, generates inputs 
and outputs between subordinate software tools and enables them to interoperate (i.e. 
exchange data and perform joint task execution). 

This portion of the dissertation research builds the needed interoperability 
ontologies by identifying and defining the essential characteristics of two software 
engineering tools: a requirements engineering tool (Rational Software Corporation's 
Requisite®Pro, a main-stream, complex, commercial tool) and a software prototyping 
tool (the Software Engineering Automation Tool suite (SEATools), a research model 
with tool support for developing executable software prototypes). The approach taken 
was to construct an initial (but extensible) federation ontology as well as two detailed 
ontologies related to the specific software process models of the two tools. In designing 
the federation ontology it was first necessary to analyze the structure, inputs, and outputs 
of the two individual tools, perform a domain analysis (of this subset of tools) and 
produce a feature model of that domain. In constructing the specific tool ontologies, the 
focus was on identifying the classes (and methods) that were needed to pass objects from 
one tool to another. 

Because there is currently no usable interoperability ontology for the domain of 
software development tools, it was not possible to rely on previous work in designing a 
federation ontology. Instead, this ontology had to be constructed "from scratch." 
Fortunately, there were existing methodologies for designing ontologies [USCH96] and 
[NOYNOl]. It was possible to tailor these methodologies to develop a specific 
methodology for constructing the federation ontology. The tailored ontology 

development process consists of the following steps: (1) identify the purpose and scope 
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of the ontology, (2) perform a feature analysis for the domain of software development 
tools, (3) eolleet similar oharaeteristies between different feature models, establish 
affinity relationships, and group eommonalities between the two tools to build a 
federation ontology representing these eommonalities and enter this ontology into 
Protege, (4) construet the more detailed ontologies for each tool in Protege, (5) use UML 
to represent the relationships between the three ontologies, and (6) document the 
ontologies. 

1, Step 1 -- Purpose and Scope of the Ontology 

Determining the purpose and scope of the ontology was fairly straightforward 
given the HFSE research goal and methodology. In this case the purpose for developing 
software development tool ontologies is to support the federation and component 
ontologies required in Young's OOMI interoperability methodology. The FIOM created 
using the ontologies establishes the basic interoperability construct of the HFSE. In 
terms of scope, the federation ontology must be broad enough to accommodate all 
potential software development tools, as well as being extensible in case new ontology 
terms and relationships have to be added later. The specific development tool ontologies 
must be detailed enough to account for the software processes and objects actually 
employed by the software development tools. The existing software API (in the case of 
Requisite®Pro) and the source code classes (in the case of SEATools) to a large extent 
dictated the level of detail and scope of the tool ontologies. 

2. Step 2 -- Feature Modeling 

The second step in the ontology design methodology was to perform a domain 
analysis of software development tools by constructing and then considering the feature 
models of Requisite®Pro and SEATools. 

Feature modeling is a method used to help define software product lines 
and system families, to identify and manage commonalities and variabilities between 
products and systems [CZAROO]. Defining a feature model for an existing software tool 
provides a means to explore, identify, and define the key aspects of the existing software 
so that these aspects can then be described more fully in an ontology. It is this ontology 
that can then be used to establish interoperability between the existing software tools. 
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This approach for the analysis and the investigation of the strueture of 
inputs, outputs, and relationships of a eolleetion of individual software engineering tools 
ean be eharaeterized as a domain analysis (of this subset of tools) and the produetion of 
feature model of that domain. Domain engineering foeuses on engineering solutions for 
elasses of software systems; it introduees and implements several different kinds of 
models, sueh as feature models. The definition of feature models is an important part of 
the requirements models (developed during the domain analysis). The feature model ean 
be viewed as an abstraet representation of funetionality found in the domain and thus 
eaeh feature is a potentially relevant eharaeteristie of the domain — "potentially" beeause 
the feature also has to be eonsidered in light of the purpose and seope of the ontology. 
Feature models represent an explieit model of a deviee or system by summarizing the 
features and the variation points of the deviee/system. Features in a feature model 
inelude the rationale and the stakeholders for eaeh of feature. A feature model for 
software system eaptures the reusability and eonfigurability aspeets of reusable software. 
Feature models provide the means to eapture the underlying organization of features in a 
feature diagram. In the ease of this dissertation researeh, the domain analysis and feature 
models were reverse-engineered from the existing software tools instead of being 
forward-engineered through examination and eonsideration of eoneepts in the domain. 

As an example. Figure 29 illustrates a feature model of a how PSDL 
timing eonstraints are implemented in SEATools. Sueh diagrams provide for rieh 
expression of subtle implementations — note that even though a "Finish Within" and 
"Minimum Calling Period" are normally required timing eonstraints, SEATools leaves 
these as optional and eompletes them for the user if they are left blank (e,g SEATools 
ealeulates EW=PER and MCP=MRT-MET respeetively). 
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Alternative Features Mandatory Feature Optional Feature 

Figure 29 Feature Model of the PSDL Timing Constraints of SEATools 

(after [HASN03]) 

The feature model is defined around concepts and not around classes of objects. The 
objective is to model features of elements and structures of a domain, not just objects in 
that domain. For more detail on the mechanics of how to construct a Feature model, 
consult [CZAROO], [GEYEOO], or [HASN03]. 

[CZAROO] provides an excellent methodology for gathering the 
information needed to construct a feature tree. He identifies the sources of features as the 
following: 

• Existing and potential stakeholders, 

• Domain experts and domain literature, 

• Existing systems, 

• Pre-existing models (e.g., use-case models, object models...), and 

• Models created during development (i.e., features gotten during 
design and implementation). 

He goes on to identify the following strategies for identifying and capturing features: 

• Eook for important domain terminology that implies variability. 

• Use feature starter sets to start the analysis. 

• Update and maintain feature models during the entire development 
cycle. 

• Identify more features than you initially intend to implement. 
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[CZAROO] then provides the following set of general steps in feature modeling proeess: 

• Reeord similarities between instanees (i.e. eommon features). 

• Reeord differenees between instanees (i.e. variable features). 

• Organize the features in feature diagram into hierarehies with 
elassifieation (mandatory, optional, alternative, and/or optional 
alternative features). 

• Analyze feature eombinations and interaetions. 

• Reeord all the additional information regarding features. 

These steps are referred to as the “miero-eyele” of feature modeling beeause they are 
exeeuted in small, repetitive eyeles [CZAROO]. While this methodology and strategy was 
useful in eonstrueting the feature tree for Requisite®Pro and SEATools, this 
methodology only provided a guide for the aetual work. The main differenee between 
this proposed methodology and the aetual methodology used eentered around the idea 
that in this partieular ease, the goal was to "reverse-engineer" feature trees from existing 
software products; not attempt to define feature trees for prospective software products. 

3, Step 3 - Establishing Commonalities 

After producing a feature model for Requisite®Pro and SEATools, the next step 
required was to isolate and annotate the commonalities that exist between the two feature 
models. These common features then formed the basis for the basic ontology 
terminology of the software development tool federation. The approach in this step was 
to reason about the two feature diagrams, develop lists of potential terms from the feature 
diagrams, identify common terms between the two lists, then construct affinity diagrams 
of these common terms. Affinity diagrams are hierarchical Venn diagrams that provide 
groupings of related terms. Eigure 30 illustrates how an affinity diagram is constructed; 
in this case the related terms all deal with "Actors" in the software development process. 
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Figure 30 Construction of an Affinity Diagram 


The groupings of terms in the affinity diagrams then provided the basis for the hierarehy 
of terms in the software development tool federation ontology. These terms and 
hierarchy were then entered and stored in the Protege-2000 ontology capture tool. This 
software development tool federation ontology is then left open for further future 
enhancement and extension. 

4, Step 4 - Tool Ontologies 

After constructing the federation ontology for the software development tool 
domain, the next step required construction of the detailed ontologies of the tools to be 
integrated into the HFSE (Requisite®Pro and SEATools). In the case of the tool 
ontologies, the detail needed for interoperability was dictated by the detail available 
through the API or source code (which ever was available) of the tool. Eor 
Requisite®Pro (a commercial tool) the tool ontology was derived directly from the 
Common Object Model (COM) API of the tool (Rational calls this interface the 
"Requisite®Pro Extensibility Interface"). In the case of SEATools, the source code was 
available; therefore, the ontology was derived from a selected set of classes and public 
methods related to the artifacts that were to be transmitted to (or received from) other 
software tools. 

During this ontology construction process, [GRUB95]'s guidelines for ontology 
construction were adhered to as much as possible: clarity, coherence, extensibility, 
minimal ontological commitment, and minimal encoding bias. However, because it was 
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necessary to adhere closely to the actual class constructs of the tools themselves, it was 
often not possible to satisfy each of these guidelines. In fact, "minimal encoding bias" 
was not adhered to at all; because to later achieve interoperability, the encoding had to 
exactly match the class, method, and attribute structures of the API and source code. As 
the terms of each tool ontology were identified they were input into the Protege-2000 
ontology capture tool. This tool makes it possible to generate XML schemas of the 
classes in the ontology. These XML schemas are the required input for Young's OOMI 
IDE. 

5, Step 5 - UML Representation of the Domain 

The fifth step in the ontology design methodology required that the relationships 
between all three ontologies be identified and annotated. The reason for this was to 
formulate inter-relationships between the ontologies so that they conform to the general 
organization required for Young's OOMI. The basic object structure of OOMI requires 
that the ontologies between the federation representation of a real world entity and the 
ontologies of the component representations of the same entities be related through the 
use of UML. Figure 31 illustrates the general UML structure that was used to annotate 
how all three ontologies were related. 



Figure 31 Ontology Inter-relationship (after [HASN03]) 

Such representations then make it possible to construct a FIOM — the set of all federation 
entities in the domain. Based on the FIOM, the OOMI IDE generated translators that 
were embedded in middleware that actually performed the translations between the two 
tools. 
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6. Step 6 -- Documentation 

The three ontologies developed for this dissertation researeh were self- 
doeumenting. The purpose, seope, and methodology used for designing the ontologies 
are presented here in this dissertation and in [HASN03]. The domain analysis and UML 
diagrams showing the key inter-relationships between the three ontologies are presented 
in [HASN03]. Excerpts from the complete ontologies are presented in [HASN03] and 
the complete ontologies themselves are stored in Protege project files. Such 
documentation makes it possible for future researchers to modify the ontologies or add 
additional tools to the ontology set. 

As a final note about the methodology used to develop these initial software 
development tool ontologies, a modified version of this methodology should be used 
when adding additional tools to the HFSE federation. The modified methodology 
includes the following: 

• In Step 1: Confirm that the purpose is still valid; expand the scope 
to include the new tool ontologies; remove any existing tool 
ontologies from the framework that are no longer needed or are 
invalid. 

• In Step 2: Only perform enough feature modeling of the new tools 
so that needed constructs for the federation ontology are identified. 
Since the federation ontology is already established it is only 
necessary to extend and modify it, not re-build it entirely. 

• In Step 3: Modify the federation ontology to account for the 
new/modified ontology terms from Step 2. 

• In Step 4: Perform the same Step 4 methodology as delineated 
above. 

• In Step 5: Modify each UME relationship diagram as needed to 
account for the new tool ontologies and the changes to the 
federation ontology identified in Step 3. 

• In Step 6: Perform the same Step 6 methodology as delineated 
above. 

This modified methodology makes it possible for future researchers to easily add 
additional software development tools to the HFSE. 

C. DOMAIN ANALYSIS AND FEATURE MODELS 

In Step 2, of the methodology above, a domain analysis was undertaken of the 
software development tool domain. The analysis was accomplished by examining two 
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specific software development tools, building feature models of those tools, and then 
identifying key terminology of the feature models. There are two reasons why this 
domain analysis cannot be considered to be a complete analysis of the domain of 
software development tools. First, only two tools (out of many hundreds of possibilities) 
were analyzed. Secondly, a domain analysis is not an “additive” activity; simply 
analyzing additional tools (beyond those two) by themselves does not completely add to 
the overall analysis. The ways in which the new additions affect and change the 
previously established analysis must also be considered. Therefore, the limited domain 
analysis conducted as part of this research can be considered a necessary, but not 
sufficient, analysis towards establishing the HFSE. 

1. Rational Requisite®Pro 

The first tool analyzed in the domain analysis was Rational Corporation's 
Requisite®Pro, a large commercial requirements management tool. The Feature Model 
was developed by identifying software features from the Requisite®Pro User's Guide 
[RATIO 1] and by actual day-to-day use of the tool. See [HASN03] for the complete 
Feature Model for Requisite®Pro. Figure 32 illustrates a single excerpt from the overall 
Feature Model for Requisite®Pro. 
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Figure 32 Excerpt of the Requisite®Pro Feature Model (after [HASN03]) 

This excerpt illustrates the features associated with the requirements' traceability 
functionality of a Requisite®Pro and is just a small portion of the total functionality (a 
small subset of the features) of the entire tool. 

From the complete Feature Model of Requisite®Pro, it was then possible to 
extract relevant features (with their descriptions). Each of these features then becomes a 
candidate for possible inclusion in the federation ontology. The complete list of 
Requisite®Pro features is listed below in Table 7 [F1ASN03]. 


Ref# 

Feature 

Description 

1 

Requisite®Pro 

A requirements management tool 

2 

Management 

Documenting and managing requirements throughout 
the development lifecycle 

3 

Requirements 

analysis 

Requirements linking, tracing, and report generation 


103 



































Ref# 

Feature 

Description 

4 

Non-functional 

features 

The subset of non-funetional features of the tool (e.g. 
integration with other tools, seeurity, and remote 
usage via web) 

5 

Manage projeets 

Projeets are the top-level objeets managed by 
Requisite®Pro 

6 

Manage teams 

Group members of the projeet team for working in a 
eollaborative environment 

7 

Manage doeuments 

Capture, eommunieate, organize, and traek doeument 
information 

8 

Set up new projeet 
template 

Creates new projeet templates from existing projeets 

9 

Remove a projeet 
from projeet list 

Remove projeets from projeet list 

10 

Allow projeet 
revision 

Allow the revision of the projeet 

11 

Unify teams 

Unify projeet managers, QA managers, testers, 
developers, ete. in eommunieating and managing 
systems requirements 

12 

Allow Interaetion 
with stakeholders 

Reeords stakeholder eommunieations and deeisions 
made about requirements 

13 

Provide standard 
projeet templates 

Customers ean use Rational Requisite®Pro's 
predefined projeet struetures or define their own 

14 

Report statisties 

Requirement metries provide projeet managers with 
statisties to be displayed in Exeel 

15 

Provide isolated 
database 

Eaeh projeet is maintained in its own sub-direetory 

16 

Synehronize textual 
Software 

Requirements 
Speeifieation (SRS) 

Synehronize textual SRS with database eontents 

17 

Manual revision of 
the projeet 

Allow manual revision of the projeet 

18 

Automatie revision of 
the projeet 

Allow automatie revision of the projeet 

19 

Notify teams 

Keep everyone informed of the eurrent requirements 
information 

20 

Diseuss and query 

Enables threaded diseussions on requirements 

21 

Provide eollaborative 
design environment 

Allows eollaborative diseussions among the team 

22 

Reeord eomments 

Provides reeording meehanisms, saves 
eommunieations to the projeet database 

23 

Provide Consisteney 

Consisteney is eheeked by other members of the 
eollaborative team 
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Ref# 

Feature 

Description 

24 

Provide 

Synchronization 

Requirements database is continually updated as new 
information is entered and recorded 

25 

Improve Efficiency 

Provides mechanisms for better communication 

26 

Improve 

Understandability 

Team members are informed of the current 
requirements information with traceability to early 
design decisions 

27 

Improve 

Effectiveness 

Optimizes team collaboration around the 
requirements 

28 

Easy Access to 
documents 

Provide access to all requirements for every team 
member, by using a central database 

29 

Customize user 
documentation 

Customers tailor documentation to their roles and 
preferences 

30 

Maintain documents 

Provides a document repository 

31 

Archive 

Allows the archiving of old documentation 

32 

Detect documentation 
changes 

Automatically detects changes to existing 
documentation 

33 

Monitor links 

Defines traceability relationships or links between 
individual requirements and between requirements 
and other system elements 

34 

Set up links 

Create relationships between artifacts in either the 
Word or View Workplaces 

35 

Identify and clear 
suspect links 

Relationships between previously linked 
requirements are marked as suspect if the text, type, 
or attributes of either requirement is changed. This 
relationship can be cleared in either Word or View 
workplaces 

36 

Automatic set to 
“suspect” 

Allows links to be automatically set to “suspecf ’ 

37 

Manual set to 
“suspect” 

Allows links to be manually set to “suspect” 

38 

Automatically clear 
suspect links 

Provides automatic clearing of suspect links 

39 

Manually clear 
suspect links 

Provides manual clearing of suspect links 

40 

Provide traceability 

Provides views of chained relationships between 
requirements 

41 

Control requirements 

Controls the access of multiple users, which provides 
control at both the project and document level 

42 

Create requirements 

Creates requirements through Word or a View 
Workplace 

43 

Edit requirements 

Edits requirements through Word or a View 

Workplace 

44 

Verify requirements 

Ensures that requirements serve as direct input to test 
creation 
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Ref# 

Feature 

Description 

45 

Update requirements 

Updates the Word Workplace when the requirement 
text in the document is modified and the document is 
saved 

46 

Add requirements 

Adds requirements to the requirements database 

47 

Delete requirements 

Deletes requirements or requirement attributes 
without disrupting work elsewhere 

48 

Provide 

requirements’ type 

Defines different types of requirements 

49 

Assign attributes to 
requirements 

Defines different attributes for different types of 
requirements and set attribute values for individual 
requirements 

50 

Prioritize 

requirements 

Provides a prioritization attribute 

51 

Relocate previous 
requirements 

Relocates previous requirements 

52 

Save requirements 

Saves requirements to the project database 

53 

Label Requirements 
temporarily 

Provides a "change pending” function, until the 
change is appropriately approved 

54 

Uniquely identify 
requirements 

Assigns a unique identifier to each requirement 

55 

Facilitates 
requirements 
coverage analysis 

Developers can assess whether they have 
documented in detail all features 

56 

View approved use- 
case 

Connects requirements with use-case models 
instantly accessible by developers. It help to ensure 
that the implemented functionality reflects the 
customer needs 

57 

Track all 
requirements 

Provides views that track the status and attributes of 
all requirements 

58 

Set requirements 
relationships 

Establish relationships among requirements 

59 

Organize 

Requirements 

Organizes requirements by type 

60 

Establish requirement 
hierarchies 

Arranges the requirements’ attributes in a hierarchy 

61 

View chain of 
relationships 

Views requirements’ chain of relationships 

62 

Sort the requirements 

Sorts requirements according to user specified 
attributes 

63 

Filter the 
requirements 

Filters requirements according to user specified 
attributes 

64 

Facilitate the 
Understanding of the 
impact of changes 

Provides views for impact analysis tailored to each 
team member 
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Ref# 

Feature 

Description 

65 

Report generation 

Automatically generates user defined reports 

66 

Tailors usability 
options 

Provides the ability to specific and set usability 
options 

67 

Remote use via web 

Includes web interface for database query, 
discussion, and for updates to requirement attributes 

68 

Provides tutorial 

Includes learning aids, such as tutorial and/or sample 
projects 

69 

Word environment 
and import wizard 

Allows extraction of textual requirements from 
external Word documents 

70 

Integration with 
software tools 

Integrates with other Rational tools, such as testing, 
design, and project management 

71 

Reduee errors 

Collaborative environment helps ensure that errors 
are identified early and fully corrected 

72 

Provides Seeurity 
meehanisms 

Permissions to access particular features are assigned 
to specific groups 

73 

Finds eurrent version 
of doeument 

Web access provides stakeholders the most-up-to- 
date requirements 

74 

Faeilitates eontextual 
understanding 

Allows the user to capture information about the 
context from which a requirement has been derived 

75 

Set user seeurity 
privileges 

Defines users and groups and their access privileges 

76 

Eoek doeuments 

Applies locking to selected documents 


Table 7 Requisite®Pro Feature List (after [HASN03]) 


This feature list is taken direetly from the Requisite®Pro Feature Model. The features 
towards the beginning of the list are high-level "parent" features, while those towards the 
bottom represent more detailed "atomie" features. 

2. SEATools 

The seeond tool analyzed during the domain analysis was the Naval Postgraduate 
Sehool's Software Engineering Automation Center's (SEAC) Software Engineering 
Automation Tool Suite (SEATools). This suite is a researeh oriented set of prototyping 
tools for designing and building exeeutable software prototypes of large eomplex, real¬ 
time software systems. The SEATools Eeature Model was developed by identifying 
software features from the SEATools deseriptions [EUQI88, 91a, 91b, 96] and by aetual 
day-to-day use of the suite. See [HASN03] for the eomplete Eeature Model for 
SEATools. Eigure 33 below and the earlier presented Eigure 29 illustrate exeerpts from 
the overall Eeature Model for SEATools. 
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Figure 33 Excerpt from the SEATools Feature Model (after [HASN03]) 


This excerpt illustrates the features associated with the edit functionality of a SEATools 
and is just a small portion of the total functionality (a small subset of the features) of the 
entire suite. 

From the complete Feature Model SEATools, it was then possible to extract 
relevant features (with their descriptions). Each of these features then becomes a 
candidate for possible inclusion in the federation ontology. The complete list of 
SEATools features is listed below in Table 8 [HASN03]. 


Ref# 

Feature 

Description 

1 

SEATools 

An integrated set of software engineering tools 
for developing prototypes of real-time systems 

2 

Management prototype 

Manage prototypes developed in SEATools 

3 

Build prototype 

Constructs the prototype (model, code, etc.) 
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Ref# 

Feature 

Description 

4 

User interface 

Provides an interface to accept user commands 
and provide information to the user 

5 

Develop systems 

Develop functional prototypes 

6 

Analyze requirements 

Analyze requirements through evolutionary 
prototypes 

7 

Generate code 

Automatic generation of the code 

8 

Model editor 

SEATools editor that provides a user the interface 
to create a software model 

9 

Modification 

Modify existing prototypes and graphs 

10 

Graphical editor 

Edits the graphical view of the software model 

11 

Expert-system design 
mode 

Provides a user interface that allows the user to 
access SEATools 

12 

Debugger 

Identifies bugs in the software model 

13 

Browser 

Provides navigability to different portions of the 
software model 

14 

Evolutionary prototype 

Maintains evolutionary prototype versions and 
variants 

15 

Eeasibility 

Supports software feasibility studies through 
prototype construction 

16 

Project control 

Assures control of projects via the use of merger 

17 

Interaction 

Allows interaction with the proposed system with 
its environment 

18 

Constraints 

Allows users to input timing constraints 

19 

Software base 

One of the five categories of the SEATools 
software 

20 

Execution support system 

The window in which SEATools is initially 
invoked 

21 

Creation 

Allows the creation of a prototype, PSDE, and 
graphs. 

22 

Add 

Allows the adding of information to an existing 
prototype 

23 

Refine systems 

Allows changes in an existing prototype 

24 

Deletion 

Allows the deletion of undesired information 

25 

Allow communication 

Allows communication between different parts of 
the model 

26 

Control communication 

Controls communication between different parts 
in the model 

27 

Tools 

Differentiates tools 

28 

Integration of complex 
systems 

Supports integration of complex systems 

29 

Design 

Assessment of design 

30 

Evolution control 
systems 

Provides automated support for coordinating the 
multiple versions of design 
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Ref# 

Feature 

Description 

31 

Merger 

Provides automated prototype change-merging 

32 

Subsystems 

Allows users to generate subsystems 

33 

Software design 

Manages the software design 

34 

Design base 

Provides persistent storage of the prototype 
development data 

35 

Translator 

Translates PSDE into Ada code 

36 

Seheduler 

Creates schedules for timing requirements 

37 

Compiler 

Compiles the source code 

38 

Execute system 

Executes all the Ada code for the currently open 
prototype 

39 

Designer 

Designs a prototype 

40 

User 

One of the potential stakeholders in a project 

41 

Prototype 

A software model that implements some subset of 
requirements for later delivered software system 

42 

Help 

Assist the user/software engineer when requesting 
information about one of the menu buttons 

43 

Edit 

Provides the ability to edit portions of the 
prototype (PSDE, Ada,, Requirements...) 

44 

Essential 

A category of differentiation for user interfaces, 
editors, the execution support system, the project 
control system, and the software base 

45 

Very useful 

A category of differentiation for user interfaces, 
editors, the execution support system, the project 
control system, and the software base 

46 

Useful 

A category of differentiation for user interfaces, 
editors, the execution support system, the project 
control system, and the software base 

47 

Conflict detection 

Detect timing conflicts 

48 

Warning 

Warns of any existing conflict 

49 

Design database 
containing PSDE 

Contains the PSDE descriptions and working 
code for all available reusable software 
components 

50 

Construction 

Allows the construction of a prototype 

51 

New 

Allows the user to create a new prototype 

52 

Quitting 

Quits and closes the SEATools program 

53 

Commit work 

Allows prototype design to be entered into the 
database 

54 

Retrieve from database 

Allows the user to retrieve data from the database 

55 

Choice 

Allow the choice of project type 

56 

PSDE 

Construct prototypes using a combination of 
graphical and textual objects 

57 

Interface 

Invokes Transportable Applications Environment 
Plus (TAE+j to edit the prototype interface 
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Ref# 

Feature 

Description 

58 

Requirements 

Allows designers to edit a requirements file 

59 

Ada 

Allows designers to edit Ada implementation 
files 

60 

Caps default 

Allows designers to ehoose whieh text or Ada 
editor will be used 

61 

Hardware model 

Eets designers eheek timing eonstraints relative to 
a maehine faster or slower than the maehine that 
is exeeuting CAPS 

62 

Operating systems 

Allows designers to aecount for operating system 
in the prototype design 

63 

Assembler 

Allows designers to aeeount for operating system 
the assembler in the prototype design 

64 

Programming language 

Allows designers to aeeount for programming 
language in the prototype design 

65 

Computer systems 

Allows designers to aeeount for hardware in the 
prototype design 

66 

Libraries 

Provides libraries for use in prototypes 

67 

Editors 

Provides prototype editors 

68 

PSDL speeifioations 

Traek PSDE speeifioations 

69 

Exeeuted eode 

Traok exeeuted eode 

70 

Graphieal objeets (data 
flow diagram) 

Allow the oonstruotion of data flow diagram 

71 

Textual objeets 

Construots and edits textual objeets 

72 

Data flow diagram 

Shows existing data flow diagram 

73 

Computational graphs 

Construots and edits oomputational graphs 

74 

binding 

finds prototype graphs 

75 

Retrieval 

Retrieve prototype from the database 

76 

Graphieal design 

Create graphieal design 

77 

Edit graphieal design 

Edit graphieal design 

78 

View graphieal design 

View graphieal design 

79 

View eode 

View eode 

80 

Edit eode 

Edit eode 

81 

Eibrary reused eode 

Use the Reuse Eibrary 

82 

Control eonstraints 

Controls the prooess and output generation via a 
set of oonditions or predioates 

83 

Operators 

Allows the drawing of operators (oiroles) in a 
data flow diagram 

84 

Streams 

Allows the drawing of data streams (direoted 
lines) in a data flow diagram 

85 

Terminator 

Allows the drawing of terminators (reotangles) in 
a data flow diagram 

86 

Timing eonstraints 

Allows the entry of Timing eonstraints 

87 

Ada SDE 

A text editor for editing Ada eode 
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Ref# 

Feature 

Description 

88 

Other text editor 

Used to view and edit text and eode 

89 

Vi 

A text editor for editing Ada eode 

90 

Emaes 

A text editor for editing Ada eode 


Table 8 SEATools Feature List (after [HASN03]) 


This feature list is taken direetly from the SEATools Feature Model. As in the ease of the 
Requisite®Pro feature list, the features towards the beginning of the list are high-level 
"parent" features, while those towards the bottom represent more detailed "atomie" 
features. 


D, FEDERATION ONTOLOGY 

After performing a domain analysis using an in-depth investigation of 
Requisite®Pro and SEATools, the two lists were eonsidered together to identify 
eommonalities — eommonalities that would also likely be eommon with other software 
development tools. These eommonalities begin to form the list of terms that eventually 


will make up the federation ontology. Table 9 lists the eommon terms from the domain 
analysis [HAS03]. 


Ref# 

Feature 

Description 

1 

Tool 

A software development tool 

2 

Actor 

Individual(s) participating in one or more roles 
in a software development effort 

3 

Stakeholders 

A person, group, or organization with a stake 
in the outcome of an application that is being 
developed 

4 

Developers 

The software engineers who develop a 
software system 

5 

Designers 

The software engineers who design a software 
system 

6 

Architects 

The software architects for a particular 
software system 

7 

Team 

A team involved in any software project 

8 

Activity 

A sequence of actions undertaken by actors or 
the tool 

9 

Communication 

Transmission and receipt of information 

10 

Management 

Control and direction over all or part of a 
software development effort 

11 

Organization 

Arrangement of the software artifacts or 
information related to a software project 
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Ref# 

Feature 

Description 

12 

Sorting 

Arrangement of the software artifacts or 
information related to a software project using 
user defined criteria 

13 

Filtering 

Removal of undesired information using user 
defined criteria 

14 

Synchronization 

Provides software project stakeholders and 
information to operate at the same rate and 
time 

15 

Archiving 

Storage of particular information related to 
software activities 

16 

Maintenance 

The process of repair, modification, and 
enhancement of a system 

17 

Creation 

The initial formation of a software artifact 

18 

Coding 

The activity actors perform to generate Code 

19 

Modification 

Changes to an existing artifact 

20 

Verification 

Confirming that an artifact is correct 

21 

Artifact 

Data, source code, or information produced, 
gathered or used during the software 
development process 

22 

Documentation 

Recorded information about the software 
development process 

23 

Statistics 

Numerical data related to the software 
development process 

24 

Database 

A collection of arranged data available for easy 
and fast retrieval 

25 

Feedback 

The provision of information to actors for 
comparison purposes 

26 

Efficiency 

Improved activity 

27 

Links/Dependencies/ 

Traceability 

Relationships between the different artifacts in 
a software development effort 

28 

Security 

A type of dependency focused on the 
avoidance of risk and danger 

29 

Child Parent 

A type of dependency focused on a 
hierarchical arrangement of artifacts 

30 

Risk 

The chance of damage or loss 

31 

Safety 

Freedom from damage or loss 

32 

Project Component 

An individual entity within a 

33 

Requirements 

A statement of what functionality, appearance, 
and behavior are required of a software system 

34 

Model 

A view of the design of an application from a 
particular perspective 
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Ref# 

Feature 

Description 

35 

Use Case 

A model of an aetors interaetion with a 
software system 

36 

Library 

A eolleetion of information and material 
related to a projeet 

37 

Prototype 

A partial implementation of a software system 
implemented for a partieular purpose (e.g. 
eonflrm requirements, test feasibility of 
teehnology, ete). 

38 

Test 

Assure the determination, the quality, and the 
truth of a software system 


Table 9 Common Characteristics for Software Development Tool Federation (after 

[HASN03]) 

After identifying these eommon terms in the domain of software development 
tools, the terms were organized into logieal groupings using an "affinity diagram" 
teehnique (reeall Figure 30). From these affinity diagrams, it was then straight-forward 
to establish the hierarehieal strueture of the federation ontology. The eompleted 
federation ontology is shown below in Figure 34. 
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■ Tool 

■ Actor 

■ Team 

■ Stakeholders 

■ Developers 

■ Designers 

■ Architects 

■ Activity 

■ Communication 

■ Management 

■ Creation 

■ Coding 

■ Modification 

■ Organization 

■ Sorting 

■ Filtering 

■ Synchronization 

■ Archiving 

■ Testing 

■ Verification 

■ Maintenance 

■ Efficiency 

■ Artifacts 

■ ProjectComponent 

■ Requirements 

■ Model 

■ Use_Case 

■ Library 

■ Prototype 

■ Document 

■ Reports 

■ Statistics 

■ Database 

■ Feedback 

■ LinksDependenciesTraceability 

■ Security 

■ ChildParent 

■ Risk 

■ Safety 


Figure 34 Software Development Tool Federation Ontology (after [HASN03]) 

The final activity after formulating this hierarchy was to input the ontology into 
Protege. From protege it was then possible to generate XML schemas that served as the 
input to the OOMI IDE. 


E, TOOL ONTOLOGIES 

After developing the federation ontology, the next step was to develop the 
individual tool ontologies of the tools that were to be integrated into the HFSE. The level 
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of detail of these ontologies was dietated by the detail of the elasses to be used to 
establish interoperability between the tools. In the ease of Requisite®Pro this eame from 
Requisite®Pro's Extensibility Interfaee (its COM API). Figure 35 illustrates the strueture 
of about 75% of the Requisite®Pro ontology. Eaeh of these elasses has numerous 
attributes and methods (e.g. the Requirement Class has sixty attributes and methods). See 
[HASN03] for the eomplete ontology. 


o Application 


■ Projects 


■ Project 

■ 

RootPackage 


■ iPackageable 


■ Package 


■ iPackage 

■ 

Requirements 


■ Revisions 


■ Revision 


■ Requirement 


■ AttrValues 


■ AttrValue 


■ Revisions 


■ Revision 


■ Relationships 


■ Relationship 

■ 

Discussions 


■ Discussion 


■ Responses 


■ Response 


■ DiscussionLinks 


RelatedProjectContexts 


■ RelatedProjectContext 


Documents 


■ Document 


■ Reports 


Queries 


■ Query 


Views 


■ View 


RequirementBucket 

Groups 


■ Group 


■ Permissions 


■ Permission 


Users 


■ User 


DocTypes 

■ DocType 

ReqTypes 


■ ReqType 


■ Attrs 


■ Attr 


Figure 35 Excerpt of the Class Structure of the Requisite®Pro Ontology 

(after [HASN03]) 
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In the case of SEATools, the source code was available so the classes came 
directly from a subset of the source code. This subset was identified by reverse¬ 
engineering the source code in TogetherSoffs (acquired by Borland in January 2003) 
Together 6.0 Java IDE [TOGE03]. Within Together, a subset of classes and public 
methods was identified for the objects that were intended to be passed to other software 
applications. This subset formed the basis of the SEATools ontology. Eigure 36 
illustrates the complete structure of the SEATools ontology. Each of these classes has 
several attributes, methods, and properties. See [HASN03] for the complete ontology 
listing. 


o SEATools 

■ 

DataFlowComponent 

■ Edge 

■ Vertex 

■ 

PSDLTime 

■ 

DataTypeObj 

■ 

DataTypes 

■ 

TypeOp 

■ 

TimerOp 

■ 

ExceptionGuard 

■ 

OutputGuard 

■ 

V ertexProperties 

■ 

EdgeProperties 

■ 

PsdlBuilderConstants 
■ PsdlBuilder 

■ 

Token 

■ 

CompilerPrototype 

■ 

TranslatePrototype 

■ 

SchedulePrototype 

■ 

ExecutePrototype 

■ 

CapsAdaFileList 

■ 

CapsMain W indow 

■ 

CapsResultList 


Figure 36 Class Structure of the SEATools Ontology (after [HASN03]) 

Together, these two tool ontologies form the basis for the component 
representations within Young's OOMI [YOUN02b]. The OOMI EIOM was constructed 
by establishing the relationships between these two ontologies and the software 
development tool federation ontology through the use of UME. 
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F. ONTOLOGY INTER-RELATIONSHIPS 

After the federation ontology and the two component ontologies (tool ontologies) 
were defined, the next step in the methodology (step 5) required that the relationships 
between the three ontologies be identified and annotated. This was done using UML. 
Both a top down and bottom up approach were taken to identify the relationships between 
the three ontologies and record those relationships in static class diagrams (recall Figure 
31). In Young's OOMI methodology, the interoperability engineer and the ontology 
manager determine the number of real-world entities to relate based on the types of 
interoperability to be achieved. In support of this dissertation, eight such relationships 
were established [F1ASN03]. Figure 37 is an example of how the three ontologies are 
related for the relationship of "Communication." 



Figure 37 Communication Class Inter-relationships (from [HASN03]) 
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Figure 37 is just one example of how the relationships between the three ontologies are 
related. See [HASN03] for the remaining sets of relationships. 


G. CHAPTER SUMMARY 

This ehapter presented the methodology and results of the researeh effort devoted 
to establishing the set of software development tool ontologies for integration into the 
HFSE. A six-step methodology was defined and used to develop a federation ontology 
and two specifie tool ontologies. Together these three ontologies form the basis for the 
establishment of a FIOM using Young's OOMI methodology [YOUN02b]. 

The six step methodology is extensible so that additional tools ean be later 
integrated into the framework by future researchers. 
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IV. INTEGRATING QUALITY FUNCTION DEPLOYMENT INTO 
THE RELATIONAL HYPERGRAPH MODEL OF SOFTWARE 

EVOLUTION 


A, RELATIONAL HYPERGRAPH SOFTWARE EVOLUTION MODEL 

1. Overview of the Relational Hypergraph Software Evolution Model 

As previously discussed, Ham establishes a Relational Hypergraph model (RH 
model) to describe Software Evolution. This model establishes dependencies and links 
between key activities/artifacts of a software development cycle and also between 
sequential iterations and variations of cycles. The model allows the development of tools 
to manage both the activities in a software development project and the products that 
those activities produce. 

In the Relational Hypergraph model, activities and artifacts affected by the 
software evolution process are called software evolution objects and consist of "Steps" 
and "Components." The Relational Hypergraph uses a hierarchical refinement (Top-level 
objects, refined objects, atomic objects) to link these objects and establish dependencies 
(both primary dependencies and secondary dependencies) between the objects. 

Dependency Rules are recorded within the object attributes. For instance, step 
attributes might consist of the following; version and variation number, status, 
predecessor, priority, deadline, estimated duration, earliest start time, finish time, 
evaluation, manager, organizer, evaluator. Component attributes might consist of the 
following: version and variation number, hypertext, code, data, pictures, charts, movies, 
etc. 

2, Important Definitions in the RH Model 

Ham provides the following dehnitions of key entities within the RH model of 
software evolution [HARN99b]. Since the RH model forms the core of how software 
development artifacts are represented within the HFSE, the following dehnitions provide 
a foundation for the entities used in the HFSE: 
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Definition 1, (Hypergraph) [HARN99b] applied the [BERG89] definition of the 
hypergraph as follows: A {directed) hypergraph is a tuple H = {N, E, I, O) where 

1. A is a set of nodes, 

2. A is a set of hyperedges, 

3. I :E ^2^ is a funetion giving the set of inputs of eaeh hyperedge, and 

4. O : A ^ 2^ is a funetion giving the set of outputs of eaeh hyperedge. 

Definition 2. (Evolutionary Hypergraph) [HARN99b] An evolutionary 
hypergraph is a labeled, direeted, and aeyelie hypergraph El = {N, E, I, O) together 
with labeling funetions Lj^ :N and L^:E ^ A sueh that the following is true: 

1. The elements of N represent unique identifiers for software evolution 
eomponents, 

2. The elements of E represent unique identifiers for software evolution steps, 

3. The funetions / and O give the inputs and outputs of eaeh software evolution 
step, sueh that 0{e) n 0{e) ^0 ^ e = e', 

4. The funetion Ta? labels eaeh node with component attributes from the set C, 
including the corresponding version of the software evolution component, and 

5. The function Le labels each edge with step attributes from the set A, including 
the current status of the software evolution step, such that A = {s,d} ■ A' (that 
is, each element of A has the form {s, a') or {d, a'), where a' e A'). 


Definition 3. (Relational Hypergraph) [HARN99b] An evolutionary 
hypergraph H - {N, E, I, O) is called a relational hypergraph if and only if for every 
hyperedge e m. H and every input node n in 1(e), the relationship between n and e is 
primary_input or secondary_input. 


Definition 4. (Primary and Secondary Dependency) [HARN99c] If an input 
node and an output node of an evolutionary hyperedge are different versions of the same 
component, then the path from the input node via the hyperedge to the output node of the 
step is called a primary-input-driven path, and the relationship between the input node 
and the step is called a primaryJnput dependency. If an input node and an output node 
of an evolutionary hyperedge are different components, then the path from the input node 
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via the hyperedge to the output node is ealled a secondary-input driven path, and the 
relationship between the input node and the step is ealled a secondaryJnput dependency. 

As an example, Figure 38 illustrates a portion of a Relational Hypergraph model 
for a software system. 



Components: 

P Software prototype programs 
C Criticisms 
1 Issues 
R Requirements 
Steps: 

5-C Software prototype demo 
s-I Issue analysis 
s-R Requirement analysis 
s-S Specification design 


S Specifications 
M Modules 
0 Optimizations 
Pd Software product programs 

s-M Module implementation 
s-P Program integration 
s-0 Software product demo 
s-Pd Software product implementation 


Figure 38 Sample Relational Hypergraph (from [HARN99c]) 


Definition 5. (Top-Level Evolution Step) [HARN99c] Let H = {N, E, I, O) be 
an evolutionary hypergraph. A hyperedge e^E is, called a top-level evolution step if and 
only if the hyperedge e has no parent evolution step. 


Definition 6. (Atomic Evolution Step) [HARN99c] Let // = {N, E, I, O) be 

an evolutionary hypergraph. A hyperedge e e E is called an atomic evolution step if and 
only if the hyperedge e cannot be expanded to additional steps and its output set has at 
most one component. 


Definition 7. (Top-level Evolutionary Hypergraph) [HARN99c] A top-level 
evolutionary hypergraph is an evolutionary hypergraph // = {N, E, I, O) , each of 
whose hyperedges is a top-level evolution step. 
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3, Embedding QFD within the Relational Hypergraph Software 

Evolution Model 

Actually embedding key portions of the QFD methodology within the Relational 
Hypergraph model requires several additions and ehanges to the RH model of software 
evolution proposed by [HARN99e]. 

a. Project Schema 

The HFSE relies on a project schema as an initial basis for a particular 
software development process. This schema can be viewed as an abstract representation 
of the different types of artifaets and different activities within a software development 
effort. The “Waterfall Model,” “Spiral Model,” and “Evolutionary Proeess Model” are 
general examples of projeet sehemas; however, a software engineer should explicitly 
identify the types of artifaets (eomponents) and aetivities (steps) within their partieular 
HESE projeet sehema. Eormally, a projeet schema is a top-level evolutionary hypergraph 
expressed as follows: 

Definition 8. (Project Schema) A project schema is the top-level evolutionary 
hypergraph H = (A, E, /, O) of a particular software development effort. 

b, QFD Dependency 

Rather than relying on the matrix seheme produced by [AKAO90] or 
[ZEiET90] Eamia proposes a different notation for the labeling of QED matrices 
[EAMI95]; this notation will be adopted for the remainder of this dissertation. Eamia 
simply uses a "A x B" notation where A is the type of artifact/component on the left hand 
side of the QED matrix and B is the artifaet/eomponent aeross the top of the matrix (e.g. a 
Risk to Speeifioation matrix would be labeled "Risk x Speeifieation", or the "roof 
portion of the matrix would be labeled "Speeifieation x Speeifieation"). This leads us to 
define the relationship between any two sets of eomponents as a QED Correlation. A 
QED Dependency is a particular type of relationship that exists between components. 
These are formally defined as follows: 

Definition 9. (QFD Correlation) Eet H = {N, E, I, O) be a relational 
hypergraph and Cj c A and Cj c A be two sets of eomponents in the hypergraph where 
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every element of C; is of the same type and every element of C 2 is of the same type. If 
there exists a hyperedge between C/ and C 2 then the QFD Correlation for the QFD 
matrix C 1 XC 2 is the adjaeeney matrix between C; and C 2 such that nonzero 

values in represent the strength of relation between adjacent components. 

Definition 10. (QFD Dependency) Let H = {N, E, I, O) be a relational 
hypergraph and C = . .,c^} c be a set of components in the hypergraph of the 

same type. A QFD Dependency D is an attribute of C such that for each 
\<i<m, D{c-) = t/. e M. 

Definition 11. (QFD Dependency Deployment) Let H = {N, E, I, O) be a 

relational hypergraph and Cj c A and Cj c A be two disjoint sets of components in the 

hypergraph where every element of C/ is of the same type and every element of C 2 is of 
the same type. If there exists a hyperedge between C; and C 2 and a QFD Dependency 
Dj = (dQ on Ci, then the QFD Dependency Deployment for the QFD matrix Ci x C 2 is the 

vector Dj = {dQ such that D^ = and '^dj = '^d.. 

j i 

B. THE MATHEMATICS OF DEPENDENCY DEPLOYMENT 

Underlying the deployment of any dependency is a sequence of matrix 
multiplications that follow from the values of the particular dependency and the values of 
the correlation matrix associated with the two components that the dependency is to be 
deployed across. 

1. Deployment Equations 

First consider a typical "downstream" deployment of dependency from 
component A to component D as illustrated in the QFD matrix in Table 10. 



Table 10 "Downstream" Dependency Deployment 
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Let A be a veetor of values of a partieular QFD Dependeney of order m (see 
Equation 4). 

A = [aj, a^, a„] Equation 4 

As expressed in Equation 5, let co be a sealar equal to the sum of those 
dependeneies (in essenee this beeomes the "amount" of the dependeney to be deployed 
aeross the design). 


Cfl = Equation 5 

i=\ 

Eet B be the QED Correlation matrix between two sets of eomponents of order 
mxnsLS expressed in Equation 6. 


B = 



■'ll 


-'ll 




Equation 6 


As expressed in Equation 7, let E be the veetor result of AB with order n, and let 
Cl be the sealar sum of the values of E. 


E = AB and Cj = ^ Equation 7 

j=i 

To maintain a eonstant value of the dependeney during the deployment, D is the 
veetor result of the dependeney deployment and is normalized with respeet to co as 
expressed in Equation 8. 

D = —E and Cj = . = Cq Equation 8 

,;=i 

Note that cs = cq (the "amount" of the dependeney remains eonstant throughout the 
deployment). 

What remains is to determine whether it is possible to deploy a dependeney 
baekwards (upstream) through a QED matrix (i.e. is it possible to find the original A, 
given dependeneies D and eorrelations B — see example in Table 11). 


126 





D1 

D2 

D3 

D4 



di 

di 


-a 

3 

d4 

A1 

fli 

bn 

bi 

i 

b 

13 

b\4 

A2 

fl 2 ^ 



2 

b 

23 

624 

A3 

«3 



~b 

33 

634 


Table 11 "Upstream" Dependency Deployment 

To investigate whether this is possible, eonsider the following derivation. Combining 
Equation 7 and Equation 8 then solving for A leads to Equation 9. 

D = — AB Equation 9 

Cl 

If B'^ exists, rearranging terms and taking advantage of the faet that co = ci, leaves 
Equation 10. 

A = — DB'^ Equation 10 

C3 

But there are two problems with Equation 10. Eirst, seldom will B be square and 
invertible (thus our assumption that B‘^ exists is likely invalid) and secondly, there is no 
way to determine the value of c/ without knowledge of A (recall Equation 7). 

This second dilemma remains even if a right pseudo-inverse for a non-square B is 
found and used. To illustrate this dilemma, consider the following derivation. By 
definition let B^be the right pseudo-inverse of B as shown in Equation 11. Eollowing 
from Equation 9 leads to Equation 12. 

BB^ = I Equation 11 

DB; = ^ abb; Equation 12 

Cl 

Rearranging terms and taking advantage of the fact that cq = cs, leaves Equation 13. 

A = — DB; Equation 13 

C3 

The dilemma with finding the inverse of B has been solved but the dilemma of not being 
able to determine the value of c; without knowledge of A remains. 
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2, Downstream Dependency Deployment Example 

The above relationships for deploying dependency across a QFD matrix can be 
illustrated with the following small example. 

Suppose that the software customer would like to deploy a value of risk 
associated with requirements across the design to specifications (see Figure 39). 

Develop Specs 

Figure 39 Deployment of Risk Example 

Suppose there are three requirements {Rl, R2, R3} with associated risk values of 
{5, 1, 3} and these are to be deployed across four specifications {SI, S2, S3, S4} (see 
Equation 14). 




A = [5 1 3] and CQ = '^a.=9 Equation 14 

/=1 

Eurther suppose that the associated QED Correlation matrix between the three 
requirements and the four specifications is as shown in Equation 15. 


B = 


0 10 3 
3 10 0 
0 0 9 0 


Equation 15 


Thus, the House of Quality prior to the deployment of risk would look as shown 
in Table 12, where D = (dj) is the vector of Specification Risk that is sought. 



Specs 

SI 

S2 

S3 

S4 

Rqt 

Risk 

dx 

di 

d3 

d4 

Rl 

5 

0 





3 

R2 

1 


3 

1 


0 


0 

R3 

3 


-0- 

-0- 

-9 


0 


Table 12 QFD Matrix for Risk Deployment Example 


The underlying Hypergraph for this QFD matrix is illustrated in Figure 40 and the 
underlying weighted digraph for the correlation matrix is illustrated in Figure 41. 
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Figure 40 Hypergraph Representation of the QFD Example 



Figure 41 Weighted Digraph Representation of the QFD Example 

Using Equation 7 and Equation 8 to calculate D (rounded to two decimal places) 
leads to Equation 16 and Equation 17. 

E = AB = [3 6 27 15] 

and Equation 16 

Cl = =51 

y=i 

D = ^E = |^E = [.53 1.06 4.76 2.65] Equation 17 
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This gives us a clear picture of how the customer's view of risk associated with 
the three requirements is "deployed" to the four specifications of the design. It intuitively 
follows that since requirements R1 and R3 had the greatest risk (5 and 3 respectively) and 
that they map most strongly to specifications S3 and S4 that these two specifications 
would end up having the greatest risk. 

But is it possible to go backwards, e.g. given the specification risk expressed in 
Equation 17, is it possible to back-out the customer's initial values of risk for the 
requirements? The answer, of course, is no — given the conclusion arrived at in 
Equation 10 and Equation 13. Because of the lack of independence in the matrix product 
E, there is no way for us to arrive at a value of 51 for ci. 

3. Upstream Deployment of Dependency 

The implication of this is significant when put in a software engineering context 
within the HESE. It means that the initial input values of dependency are anchored to a 
particular component of origin. The dependency can be deployed forward from this 
origin as shown above in Equation 4 through Equation 8. However, values downstream 
from the origin (forward along the path of development) cannot be modified and then 
reliably deployed backwards through the matrices to the origin. The best that can be 
achieved is to create a new dependency at that point (the point of dependency 
modification) and deploy that dependency backward through the design but using the 
forward calculations expressed in Equation 4 through Equation 8. In order to account for 
the proper order of D and B, the transpose of the correlation matrix B is used. Eor 
instance, given D and B we would arrive at vector A as shown through Equation 18 and 
Equation 19. 

n 

F = DB^ and Equation 18 

y=i 

A = —F and Equation 19 

C4 

In our example above, suppose that the values of risk that were arrived at in 
Equation 17 were actually original risk values determined by the software developer 
based on his assessment of how the project might fail while implementing those 
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specifications. The developer then wants to know how that risk deploys backwards 
(upstream in the development effort) to the customer's requirements so that he can 
identify the requirements that have the greatest impact on his view of risk. Applying 
Equation 18 and Equation 19 to D and B leads to Equation 20, Equation 21, and 
Equation 22. 


F = DB^ 


= [.53 1.06 4.76 2.65] 
= [9.01 2.65 42.84] 


0 3 
1 1 
0 0 
3 0 


0 

0 

9 

0 


'4 = Z/,=54.5 

y=i 


A = -^F = -^F = [1.49 .44 7.07] 
C 4 54.5 ^ ^ 


Equation 20 


Equation 21 


Equation 22 


Note that the result from Equation 22 is not at all similar to the vector in 
Equation 14. Erom the developer's point of view it is requirement R3 (not requirement 
Rl) that presents the greatest risk (this follows from the fact that specification S3 had 
such a relatively high value of risk and was so highly coupled to requirement R3). 

4, Other Means of Deploying Dependencies: Constant Range 
In deriving Equation 8 a key assumption was made that the "amount" of the 
dependency would remain constant across the deployment. This assumption impacts the 
deployment by either "thinning-out" the dependency when it is deployed across 
numerous components (from a few components) (see example in Table 13) or 
"concentrating" the dependency on just a few components (when deployed from many 
components) (see example in Table 14). 
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Specs 

SI 

S2 

S3 

S4 

S5 

S6 

S7 

S8 

S9 

SIO 

Rqt 


.41 

.48 

1.85 

1.03 

.14 

.34 

.41 

3.08 

.41 

1.85 

R1 

5 

0 

1 

0 

3^ 




1 

0 

9 

0 

0 

R2 

2 

3 

1 

n 

n 

r 

1 


0 

3 

0 

3 

0 

R3 

3 

0 

0 

L 9 — 

- 0 — 

-0- 


0 

0 

0 

0 

9 


Table 13 Dependency Thinning (Dependency = 10) 



Specs 

SI 

S2 

S3 

Rqt 


6.33 

7.85 

25.82 

R1 

5 

0 

1 

0 

R2 

1 

3 

1 

0 

R3 

6 

0 



R4 

2 

0 



r 

R5 

4 


—0 


0 

R6 

1 

9 

0 


0 

R7 

7 

0 

0 

3 

R8 

2 

0 

3 

0 

R9 

3 

0 

1 

0 

RIO 

9 

1 

0 

3 


Table 14 Dependency Concentration (Dependency = 40) 

It is possible to use a different initial assumption when deploying the dependency: 
instead of keeping the "amount" of the dependency constant, the "value range" of each 
dependency could be kept constant. This would require the deployed dependency to be 
normalized against the possible range of the dependency. 

Let A be a vector of values of a particular dependency of order m and let depmm 
and depmax be the possible minimum and maximum values of each a, as expressed in 
Equation 23. 

A = [aj, a^, a^\, where V i : dep^^ < a. < dep^^^ Equation 23 

As shown in Equation 24, let B be a matrix of correlation values between two 
components of order mxn, and let cormin and cormax be the possible (not necessarily 
actual) minimum and maximum values of each by. 
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such that Vz, j : < by < cor^^ Equation 24 



Let E be the vector result of AB with order n shown in Equation 26. 


E = AB 

and Equation 25 

M/': (dep^Jicor^Jim) < < {dep^J{cor^J{m) 

To maintain a constant range of values for the dependency during the deployment, 
as shown in Equation 26 and Equation 27, D is the veetor result of the dependeney 
deployment and is normalized with respeet to the minimum and maximum possible 
values of ej. These normalized values are added to the minimum dependeney value 
dcpmm- 


Let G = (g^) sueh that Vy : gj = dep^^ 


Equation 26 


D = 


_ (^gPmax -dep^J _ 

[(dep^,, * cor^J- (dep^^ * cor^J]iin) 


* [E - (dep^Jicor^Jim)] + G Equation 27 


and Vy : dep^^ < dj < dep^^ 

In general QED practiee (as discussed in Chapter II) QED eorrelation values are typieally 
0; 1:3:9, thus cormin is usually zero. Since Equation 27 does not explicitly require this to 
be the case, the engineer must seleet maximum and minimum dependency values and 
correlation values with care to ensure that [{dep^^^ * - (dep^^^ * cor^^j^)] ^ 0. 

To illustrate the use of this form of deployment, consider the application of 
Equation 23 through Equation 27 to the QED deployment presented in Table 12. Let A be 
a vector of dependency values within the range [1,7] and order m=3 and let B be matrix 
of correlations within the range [0, 9]. This leads to the results in Equation 28 through 
Equation 30. 
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A = [5 1 3], B = 


0 10 3 
3 10 0 
0 0 9 0 


, G = [l 1 1 1] 


Equation 28 


dep = 1, dep = 7, cor = 0, cor = 9 

-Tmin ’ -Tmax ’ mm ’ max 


E = AB = [3 6 27 15] 


Equation 29 


D 


(«^ePmax -dep^J 


\idep^^ * cor^J- {dep^^ * cor^J](fn) 
* [E - (dep^J(cor^J(m)] + G 
(7-1) 


[(7*9)-(l*0)](3) 
^ -E + G 


[E-(l*0*3)] + G 


189 

= [1.10 1.19 1.86 1.48] 


Equation 30 


In examining the result of Equation 30 notiee that the values did remain in the 
range [dep^in, depmax]- However, while these values were obtained through a sound 
mathematical deployment methodology, the usefulness of such numbers in decision 
support is questionable. These numbers become even more questionable as they are 
deployed further and further through the design because they will continue to approach 
depram- Thc rcasou the values were particularly low (near dep^m) and why they will 
continue to get lower as they are further deployed is because of the relative sparseness of 
the correlation matrix B. Such sparseness is characteristic of QED correlation matrices 
and makes the methodology expressed in Equation 23 through Equation 27 much less 
useful from a decision support perspective than the methodology expressed in Equation 4 
through Equation 8. 

While it is possible to account for this sparseness by using the values of Cmax and 
Cmm (from E = (e^)) in Equation 27 instead of (dep^^^* cor^J and (dep^^* cor^J, 


respectively, another problem is introduced. Consider Equation 31. 
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Equation 31 


L V^max ^min) J 

and V/-: dep^^ < < dep^^^ 

In this deployment seheme the deployed values that lead to D are normalized sueh that 
the highest value of D assumes the value of depm&x and the lowest values assumes the 
value of depmin- The remaining values are spaeed appropriately based on their ratio 
within the range [t/epmin, t/epmax]- The shorteoming with this seheme is that it does not 
preserve a sense of ratio from the boundaries of the range (i.e. any boundary that should 
exist is lost in the deployment). A second and more minor shortcoming (since it is 
unlikely to occur in actual practice) is that if all of the values of E are the same, then 
emax= Cmin and the denominator of Equation 31 goes to zero making the result undefined. 

Since the reason for the deployment of dependencies is for decision support, the 
HESE will rely on the "constant dependency amount" methodology specified in 
Equation 4 through Equation 8 as opposed to the "constant dependency range" 
methodology specified in Equation 23 through Equation 27 or the methodology in 
Equation 31. This still leaves, however, the dilemma of how to make use of the deployed 
dependencies subject to dependency "thinning" and dependency "concentration" (recall 
Table 13 and Table 14). 

5. Other Mathematical Checks 

There are other mathematical checks that can be performed on a QED matrix to 
ensure that it is consistent. Eor instance, it is possible to examine the columns of a QED 
matrix to determine if any superfluous artifacts have been created. It is also possible to 
perform a "coverage" check of the QED Correlation matrix to provide visibility as to 
whether the "how" components adequately implement the "what" components of the 
design. 

a. Superfluous Artifact Analysis 

The purpose of superfluous artifact analysis is to determine if there are 
artifacts in the design that are not needed and have been erroneously introduced. This 
analysis is conducted by looking for discrepancies in column values of the QED 

Correlation matrix. A complete column of zero valued correlations is an indication of a 
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mistake in the design; either a eorrelation value was mistakenly omitted, or the “how” 
artifaet itself is superfluous to the design. As an example, eonsider the QFD matrix 
shown in Table 15 in whieh the QFD Dependeney “Requirements Priority” has been 
deployed downstream to speeifieations. 



Specs 

SI 

S2 

S3 

S4 

S5 

Rqts 

Priority 

1.4 

2.8 

4.2 

0 

3.6 

R1 

5 

0 

1 

0 

0 

0 

R2 

1 

1 

9 

9 

0 

0 

R3 

2 

3 

0 

0 

0 

3 

R4 

4 

0 

0 

3 

0 

3 


Table 15 QFD Coverage Analysis Example 


Note that the eorrelation eolurnn of S4 has only zeros for values. Sinee the overall 
purpose of the Speeifieations is to implement the stated requirements, this eolurnn of 
zeros indieates that either the engineer made a mistake in assigning eorrelation values or 
that S4 is superfluous to the design. The “0” value of the deployed priority dependeney 
value for S4 suffiees as a “red flag” for the engineer. The engineer should question 
whether or not S4 is needed in the design and if so, whieh requirements are driving that 
need. 

b. Coverage Analysis 

The purpose of performing a QFD eoverage analysis is to determine if 
adequate “hows” have been speeified for implementing the “whats” in the QFD proeess 
(e.g. have adequate speeifieations been identified for implementing the requirements). 
“Adequate” in this ease refers to whether the “how” artifaets are suffieient in quantity and 
quality to fully implement the “what” artifaets. [ZULT92] proposes that the eoverage 
analysis be performed by summing the rows of the QFD Correlation matrix, normalizing 
the result, and then comparing these normalized values against the relative weights of the 
"what" components. They should generally be the same. Mismatches are indications that 
either more (or stronger) "hows" are needed to implement a particular "what" or that 
there are too many (or too strong) "hows" that implement a "what". 

As an example of coverage analysis, continue to consider the QFD matrix 
presented previously in Table 15. Summing the correlation values by row and 
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normalizing, then comparing them side-by-side with normalized values of the 
Requirements priorities indicates several additional problems; consider the results in 
Table 16. 



Normalized Rqts 
Priority Values 

Normalized 
Correlation Row 
Sums 

Rl 

0.417 

0.031 

R2 

0.083 

0.594 

R3 

0.167 

0.187 

R4 

0.333 

0.187 


Table 16 Coverage Analysis Example: Side-by-Side Comparison 

It is clear that the requirement R1 (the most important requirement) has been severely 
underrepresented in specifications and that R2 (the least important requirement) has been 
significantly over-represented as indicated by the large difference in normalized values 
corresponding to these two requirements. The software engineer should reconsider the 
correlation values established in Table 15. The engineer might also want to identify 
additional specifications needed to fully implement Rl. Now consider the adjusted QFD 
matrix in Table 17 and the corresponding side-by-side coverage analysis values in Table 
18. 



Specs 

SI 

S2 

S3 

S4 

S5 

Rqts 

Priority 

0.75 

0.64 

3.86 

4.82 

1.93 

Rl 

5 

0 

1 

0 

9 

0 

R2 

1 

1 

1 

0 

0 

0 

R3 

2 

3 

0 

0 

0 

3 

R4 

4 

0 

0 

9 

0 

3 


Table 17 QFD Coverage Analysis Example 
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Normalized Rqts 
Priority Values 

Normalized 
Correlation Row 
Sums 

R1 

0.417 

0.333 

R2 

0.083 

0.067 

R3 

0.167 

0.200 

R4 

0.333 

0.400 


Table 18 Coverage Analysis Example: Side-by-Side Comparison 

The side-by-side eomparison in Table 18 reveals a mueh more eonsistent result. While 
the qualitative assessment illustrated in the above example demonstrates the eoverage 
analysis eoneept, the teehnique ean be supplemented with a more sophistieated statistieal 
analysis such as hypothesis testing using a “Paired t Test” [DEVOOO]. Although outside 
the scope of this dissertation, such analysis can give the engineer ever increasing 
confidence of adequate coverage of downstream components within the software design. 


C. MAKING USE OF DEPLOYED DEPENDENCIES 

The goal of deploying dependencies across the design is to allow the software 
engineer the ability to visualize "slices" of the design that have particular meaning. For 
example, if the engineer has deployed customer risk throughout the design, he may want 
to do the following: 

• Identify all components that have a relatively high value of customer risk 
("relatively" being defined by some user specified threshold value). 

• After identifying a particular component (say, with high risk) identify all 
strongly (or weakly, or any) connected components that trace to that 
component. The strength of connectivity used in the search is defined by 
the user specified threshold value. 

These two techniques are named Dependency Threshold and Component Trace, 
respectively. 

1, Dependency Threshold 

Since the range of dependency values varies widely between groups of 
components (recall dependency "thinning" and "concentrating"), it is generally not 
sufficient to simply specify a particular value of dependency and then isolate all 
components within each group of components that have dependency values greater than 
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or less than that value. However, sinee eaeh group of eomponents has been normalized 
within the group, it is possible to isolate those eomponents that are greater than or less 
than some speeified value related to their mean and standard deviation. Let t be the 
dependeney threshold value speeified against the mean and standard deviation of eaeh 
group of eomponents as shown in Equation 32. 


t = ju^± xcr. 

where x is a user speeified value and 

i identifies a partieular set of eomponents. 


Equation 32 


As an example, eonsider the QED deployment example previously presented in 
Table 12 and shown below in Eigure 42 (dependeney values of risk are shown in 
parentheses). 



Figure 42 Hypergraph with Risk Dependency Values 

The requirements eomponents and speeifieation eomponents have mean and 
standard deviations as shown in Equation 33. 


jUj^=3 and cr^ » 1.63 
jUg =2.25 and 1.65 


Equation 33 


Applying the "Dependeney Threshold" view, Eigure 43 illustrates the remaining 
subgraphs if the underlying hypergraph is trimmed at thresholds of t = //. and t = ju. + <j ., 


respectively. 
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Figure 43 Subgraphs Trimmed with Dependency Threshold 


From a decision support perspective, the Dependency Threshold view of the 
underlying hypergraph allows a software engineer to easily identify particular subgraphs 
of interest. It is relatively easily to identify those components that have the greatest (or 
least) dependency values and to base resource allocation decisions upon those views. 

2, Component Trace 

The Component Trace view of a hypergraph allows the software engineer to 
identify all connected components of a single component based on a user-defined value 
of connectedness. This technique assumes that the same ranges of values are used 
throughout the hypergraph for relating the correlation between any two components. 
Consider Figure 44, a weighted digraph representing a simple software development 
process. 

Define 

Architeetural Define 
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Component traces centered on component A3 with threshold values of 2 and 8 are 
illustrated below in Figure 45 and Figure 46, respectively. 



Figure 45 Component Trace from A3 with Threshold 2 


Define 

Arehiteetural 



Figure 46 Component Trace from A3 with Threshold 8 

Again from a decision support perspective, the Component Trace view of the underlying 
hypergraph allows a software engineer to easily identify particular subgraphs of interest. 
Using such a view it is relatively easily to identify the potential knock-on effects 
associated with changes to a particular component and to base resource allocation 
decisions upon those potential effects. 


D. ESTABLISHING DEPENDENCY VALUES 

Central to the use of the QFD methodology within the HFSE is the concept of 
dependency value deployment. "Setting priorities means advancing some actions and 
postponing others" [ZULT93]. The design realities implied by this quotation are 
substantial and while the actual dependency values used by the FIFSE are developed in 
external software development tools and then imported into the HESE, the adage 
“garbage in equals garbage ouf’ holds true. Thus, if erroneous dependency values are 
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imported into the HFSE and then deployed throughout the design, the engineer is likely 
to make poor engineering deeisions stemming from this data. Therefore, the eoneepts 
underpinning what separates good dependeney values from bad values are worthy of 
review. 

1. Scales of Measurement 

In his seminal work, Stevens [STEV46, 51] provides what is now eonsidered to 
be the standard elassifieation taxonomy for measuring both quantitative and qualitative 
variables. His taxonomy of measurement eonsists of four different ways to use numbers 
to measure everyday phenomena. These four ways of measurement eonsist of nominal, 
ordinal, interval, and ratio. 

a. Nominal 

In nominal measurement, numbers are simply used as labels for 
identifying separate entities. They denote no additional information other than 
identifieation. An example of a nominal measurement would be the random assignment 
of a student identifieation number. The number serves no purpose other than to 
distinguish one student from another and eannot be used to deduee whieh student is 
smarter or whieh student is majoring in ehemistry. Erom an HESE dependeney valuation 
perspeetive, nominal values provide no useful information about software artifaets 
(exeept to distinguish between artifaets) and thus should never be used as deployable 
dependeney values. 

b. Ordinal 

In ordinal measurement, entities are simply ordered in a partieular way: 

least to most, best to worst, worst to best, ete. In this ease, it is possible to distinguish 

whieh entity might be “better” than another, but it is not possible to distinguish how 

mueh better. Values from an ordinal seale distinguish the direetion of differenee only. 

An example of an ordinal measurement would be the assignment of finishing positions to 

a set of raeehorses eompleting a raee. While it is possible to determine whieh horse 

finished ahead of another, an ordinal scheme provides no information that would allow a 

user to determine by how much one horse beat another. Erom an HESE dependency 

valuation perspective, ordinal values might provide some marginally useful information 

about software artifacts differences but as discussed later, this information should be used 
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cautiously and results based on this type of dependeney ealeulation should be viewed 
skeptieally. 

c. Interval 

In interval measurement, the distanee between two entities is established. 
In this ease, it is possible to distinguish whieh entity is better and by how mueh using a 
seale eonsistent throughout the entire range of the seale. Interval seales do not have true 
zero points. Temperature as measured in Fahrenheit or Celsius is an example of an 
interval seale. Using an interval seale for temperature, it is possible to determine whieh 
temperature is warmer than another and by how mueh, however, beeause of the laek of a 
zero point it is meaningless to try to state that one temperature is twiee as warm as 
another. From an HFSE dependeney valuation perspeetive, interval values provide useful 
information about software artifaets and results stemming from interval values lead to 
more dependable information that those generally aehieved using an ordinal seale. 

d. Ratio 

Just as in the interval seale, in a ratio seale numbers tell the direetion and 
relative distanee between entities being measured. Additionally, however, ratio seales 
enjoy the presenee of an absolute zero so that it is possible to eompare entities in terms of 
proportions, pereentages, and ratios. Measures of distanee and mass are examples of 
ratio valuations. In measuring length, it is possible to distinguish whieh length is greater, 
by how mueh, and by what pereentage (e.g., a yardstiek is longer than a ruler, it is longer 
by two feet, or it is 200% longer). From an HFSE dependeney valuation perspeetive, ratio 
values provide the best information about differenees in the dependeneies of software 
artifaets and results stemming from ratio values lead to the most dependable information. 

While Stevens’ measurement taxonomy [STEV46, 51] appears to be the most 
widely used and aeeepted taxonomy, it is worth mentioning that there are some eritieisms 
of his taxonomy and that other taxonomies, besides his, do exist. Comparison of the 
defieieneies and potential benefits to the HESE of all of these taxonomies of 
measurement is outside the seope of this dissertation; however, interested readers are 
referred to [VEEE93] whieh provides a broad overview of the issues involved. 
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2. QFD Dependency Valuation 

Following from Stevens’ measurement taxonomy [STEV46, 51], [COHE95] 
diseusses three different ways of establishing basie values for the priority values of a set 
"whats" in the QED valuation proeess: by Absolute Importanee, by Relative Importanee, 
and by Ordinal Importanee. In terms of Stevens’ taxonomy, these eorrespond to interval, 
ratio, and ordinal, respeetively. 

a. Absolute Importance (Interval Valuation) 

In using the Absolute Importanee seheme, eaeh dependeney value is 
established based on the user's view as to the value of the dependeney eompared to a set, 
fixed, absolute seale. Eor instanee, sueh a seale might be 1-5 as shown in Table 19. 


Value 

Criteria 

1 

Not at all helpful 

2 

Of minor help 

3 

Of moderate help 

4 

Very helpful 

5 

Extremely helpful 


Table 19 Example Absolute Importance Scale 

Sueh values are usually obtained using a survey of the partieular users in 
whieh the respondents are asked to rate the importanee of eaeh item related to the 
partieular dependeney under eonsideration. At first, one might wonder why this seale is 
not eonsidered a ratio seale sinee it appears to have an absolute zero. However, while the 
interval values themselves are fixed, this lower bound is not aetually absolute. Eor 
example, there is nothing that prevents the user from later establishing a new fixed value, 
for instanee -3, for “Moderately unhelpful.” Sueh an addition would not affeet the prior 
valuations at all. A problem with this seheme is that users have a tendeney to inflate sueh 
ratings, viewing eaeh dependeney item as of moderate importanee or greater [COHE95]. 
This has the effeet of grouping the results and making them more diffieult to interpret and 
find logieal breakpoints in the data. Table 20 is an example of applying the Absolute 
Importanee seheme to a set of speeifieations where the dependeney under eonsideration is 
"Diffieulty of Implementation". In this ease the implementers use a seale of 1 to 5 where 
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1 corresponds to "easy to implement" and 5 eorresponds to "extremely diffieult to 
implement.” 


Specification # 

Difficulty 

Speeifieation 1.1 

1 

Speeifioation 1.2 

4 

Speeifioation 1.3 

4 

Speeifioation 1.4 

2 

Speeifioation 1.5 

5 


Table 20 Absolute Importance Valuation Scheme 

Note that in sueh a seheme, it is possible for multiple eomponents to have the same value 
(e.g. Speeifieations 1.2 and 1.3 both have a value of 4). 

b. Relative Importance (Ratio Valuation) 

In using the Relative Importanee seheme (also known as "ratio-seale 
importanee"), eaeh dependeney item is plaeed on a set 100 point or pereentage seale. In 
this method eaeh dependeney item is ranked ordered from least important to most 
important and then the relative differenee between the items is established (e.g. this item 
is twiee as important as the previous one, or this item is barely more important than the 
previous one, ete.). Typieal ranges of values are from about 40 to 85 [COHE95]. Table 
21 is an example of applying the Relative Importanee seheme to the same set of 
speeifieations, again where the dependeney under eonsideration is "Diffieulty of 
Implementation". In this ease the implementers used a 100 point seale where the higher 
the value, the more diffieult the speeifieation is to implement. 


Specification # 

Difficulty 

Specification 1.1 

20 

Specification 1.2 

43 

Specification 1.3 

46 

Specification 1.4 

25 

Specification 1.5 

72 


Table 21 Relative Importance Valuation Scheme 
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c. Ordinal Importance (Ordinal Valuation) 

A third scheme for establishing dependeney values is the Ordinal 
Importanee seheme. In this seheme, the dependeney items are simply arranged in order 
from least importanee to most important and assigned a value based on that order. For 
instanee, 10 items would reeeive values of 1 to 10 where 1 is the least important item and 
10 is the most important item. The other items would reeeive an ordinal value based on 
their order of plaeement. Table 22 is an example of applying the Ordinal Importanee 
seheme. 


Specification # 

Difficulty 

Specification 1.1 

1 

Specification 1.2 

3 

Specification 1.3 

4 

Specification 1.4 

2 

Specification 1.5 

5 


Table 22 Ordinal Importance Valuation Scheme 
d. Comparison of Valuation Schemes 

Dependeney values are multiplied through the QFD Correlation matrix 
and normalized to ereate values for the next set of downstream or upstream artifaets. 
While the initial dependeney values themselves may not have been generated using a 
ratio seale, the faet that they get multiplied by the proportional values of the eorrelation 
matrix and then normalized, means the values are used as if they were established using a 
ratio seheme whether they were or not. Thus, the ratio of the range of potential values 
beeomes important and this range varies by the seheme. [COHE95] provides insight as 
to the typieal range of values for 20 items under evaluation in QFD proeesses. The 
Absolute Value seale (with a seale of 1-5) will produee a seheme theoretieally between 1- 
5; but, in praetiee, this is about 3-5 or a ratio of 1:1.6. The Relative Value seheme 
generally produees values in the range 40 to 85, a ratio of 1 to 2.1. The ordinal seheme 
will produee values of 1 to 20, a ratio of 1:20. The ratios for the Absolute Value seale 
and Relative Value seale remain fairly eonstant as the number of items being eompared 
inereases; however, the ratio for the ordinal seale eontinues to grow — imagine how large 
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this ratio would be with several hundred items. Thus, using an ordinal seheme with many 
eomponents and deploying values through a eorrelation matrix will have the effeet of 
signifieantly over-emphasizing important “whats” and under-emphasizing least important 
“whats”. Even though the use of ordinal value sehemes is widespread and eommon in 
QFD praetiee, their use should be viewed with skeptieism. 

The HFSE will take advantage of using dependeney values established 
from other software development tools. For instanee, Requisite®Pro uses an absolute 
(interval) seale for requirement priority (low, medium, high), and allows the user to 
ereate user defined metries based on Relative Value (ratio sehemes). Traditional 
Japanese QFD methodologies rely on using simple Absolute seales of 1-5, with 
inereasingly sophistieated methodologies (e.g. pairwise eomparison) used to establish the 
weights. However, there is evidenee that even more eomplex methods are being used 
sueh as the Analytie Hierarehy Proeess (AHP) [ZF1FT92], whieh is a methodology based 
on ratio seales. [AKAO90] also reeommends using AHP when additional rigor is 
required to sort through and establish well-supported priorities upon whieh to base 
deeisions. While sueh teehniques as AHP require signifieantly more effort, they provide 
greater aeeuraey and support for eonsisteney eheeking and sensitivity analysis. 

In summary, many software development tools produee metries that ean 
be imported into the HFSE and deployed throughout the development effort. However, 
the engineer should be eognizant of the type of values being imported beeause the type of 
value affeets the aeeuraey and eorreetness of the deeision support information later 
produeed from those values. Ordinal values may provide some useful indieations, but the 
engineer should be skeptieal of basing eritieal or eostly deeisions upon them. Absolute 
values (using interval seales) provide mueh better results and have been reliably used in 
QFD praetiee [COHE95]. Relative values (using ratio seales) provide the best and most 
mathematieally sound valuation and results [SAAT80]. 

3, The Analytic Hierarchy Process (AHP) 

a. The Normalized Principal Eigenvector of Priority Values 

Saaty presents the Analytie Hierarehy Proeess (AHP) as a proeess to 
establish ratio valuation of a group of items through the use of pairwise eomparison 

[SAAT80]. This is typieally aeeomplished through the ereation of a eomparison matrix 
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using a set Absolute Importanee seale. Consider Table 23 in whieh four items (A, B, C, 
and D) are eompared to eaeh other using the Absolute seale provided in Table 24. 


Importance 

A 

B 

C 

D 

A 

1 

5 

6 

7 

B 

1/5 

1 

4 

6 

C 

1/6 

1/4 

1 

4 

D 

1/7 

1/6 

1/4 

1 


Table 23 Example AHP Comparison Matrix (after [SAAT80]) 


Value 

Meaning 

1 

Equally Important 

3 

Weakly more important 

5 

Strongly more important 

7 

Very Strongly more important 

9 

Absolutely more important 


Table 24 AHP Comparison Valuation Scheme 

Table 23 illustrates the eommon form of an AHP eomparison matrix: a right-hand 
reeiproeal matrix with values on the diagonal equal to 1. Typieally, appropriate groups of 
stakeholders subjeetively establish eaeh value above the diagonal; the aetual minimum 
number of eomparisons needed to eonstruet the matrix is « -1 sinee the diagonal values 
and reeiproeal values below the diagonal are foreed. 

The veetor of priority values is derived from the normalized prineiple 
eigenveetor of the of this eomparison matrix. A good approximation of this veetor is 
given by multiplying the n elements of eaeh row of the matrix, taking the n'^ root of eaeh 
result, and then normalizing the resulting vector [SAAT80]. Consider Table 25, which 
shows the approximate result from Table 23 side-by-side with the actual principal 
eigenvector. 
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Element 

Approximate 

Result 

Actual Normalized 
Eigenvector 

A 

0.61 

0.61 

B 

0.24 

0.24 

C 

0.10 

0.10 

D 

0.04 

0.05 


Table 25 AHP Example Normalized Priority Values 

b. Consistency Checking of the Comparison Matrix 

[SAAT80] also provides a sound methodology for eonfirming the 
eonsisteney of any set of subjeetively derived valuations. Beeause more subjeetive 
eomparisons are input into the eomparison matrix than are mathematieally required 
{{n^ -n)/2 versus n-\), the eomparison matrix may beeome ineonsistent and produee 
ineonsistent priority valuations. Saaty’s method for eonfirming eonsisteney depends on 
comparing the principal eigenvalue to n. The closer to n, the more 

consistent is the comparison matrix. The first step in confirming consistency is to 
calculate the consistency index (C.I.) shown in Equation 34 [SAAT80]. 

j _ 04iax—^ Equation 34 

(n-1) 

The C.I. is then compared to an empirically derived Random Index (R.I.), which is a 
measure of the possible randomness of a comparison matrix. This comparison is called 
the Consistency Ratio (C.R.) and is given by Equation 35. 

C I 

C.R. = Equation 35 

R.I. 

Consistency Ratios of 0.10 or less are considered acceptable [SAAT80]. 

c. Hierarchical Clustering to Account for Non-Independence 

The comparison matrix in Table 23 assumed that the four items were 
independent and that subjective evaluations can be independently made between them. 
However, what happens if the items are not independent of one another? Erequently, 
software engineers are asked to provide valuations for hierarchical artifacts that are not 
independent. Consider the small subset of requirements from the CARA Infusion Pump 
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shown in Table 26 in which pertinent requirements information in located in all three 
hierarchical levels. 


Tag 

Requirement Name 

Requirement Description 

FEAT7 

Occlusion Fine Monitoring 

The CARA will monitor the occlusion lines 
whenever the pump is plugged in. 

FEAT7.1 

Occlusion Detected 

If an occlusion fault is detected 

FEAT7.1.1 

Occlusion Display Msg 

An appropriate error message should is 
issued. 

FEAT7.1.2 

Occlusion Fevel 1 Alarm 

A level 1 alarm should is issued 

FEAT7.1.3 

Occlusion Terminate AC 

If an occlusion is detected while in auto¬ 
control, CARA will terminate auto-control 


Table 26 Excerpt from CARA Infusion Pump Requirements 


In applying the AHP to this particular case, “clusters” are established to form groupings 
of independent entities. The clusters here might be considered as {FEAT7} and 
{FEAT7.1, 7.1.1, 7.1.2, 7.1.3}. After establishing the appropriate weightings between 
these two clusters, the second cluster is considered separately and further clustered and 
weighted as needed. The weighting of the higher hierarchy is divided among lower level 
clusters. Consider the more complex example in Figure 47. 
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In this example, nine arehiteetural entities are eompared and weighted. Three initial 
independent clusters are established and weighted (element A2 is considered its own 
cluster). Clusters 1 and 3 are then separately and internally compared and weighted. 
While the entities internal to the clusters might not strictly independent, it is generally 
possible to evaluate the elements in clusters of nine items or less to determine the 
contribution of each element towards the overall function of the cluster. The weighting 
of the cluster is then applied to this internal comparison to arrive at a final weighted value 
for each atomic component. [SAAT80] points out that clustering also serves a second 
and important purpose and that is to decompose large, complex valuation problems into 
smaller, more manageable pieces that can be easily understood by the human mind. 

4, Subjectivity and Sensitivity Analysis 

In any human centric activity requiring judgment, subjectivity is always present. 
However, it is possible to account for this subjectivity through application of consistent 
group decision processes and to then confirm results through use of sensitivity analysis. 
Even though each person perceives the world slightly differently, it is possible to use 
consensus-building techniques to produce results that are statistically consistent with the 
overall perceptions of the group. [SAAT80] points out: 

.. .if people do not know what they are talking about, there is no scale that 
would make them look better. However, if people know something and 
they want a measure of it, then there is no better way of getting these 
judgments down than through a systematic procedure which facilitates 
comparisons, and is in harmony with intuition and human feelings, and is 
free of artificiality. If a person already knows the answer, he then has no 
need for any scale... 

As discussed in the previous section, AHP is a methodology specifically designed to use 
groups of stakeholders to perform comparisons and arrive at statistically consistent 
results. Such methods lend themselves to further evaluation through sensitivity analysis. 

The purpose of performing a QFD sensitivity analysis is to determine how 
sensitive the resulting deployed dependency values are to perturbations in correlation 
values or in the initial dependency values. While considered an area of future research 
(see Chapter IX) it should be possible to embed dedicated sensitivity analysis techniques 
and algorithms into the tool support for the HFSE. Chapter VII discusses the current 
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status of the tool support of the HFSE. While the tool eurrently does not eontain 
dedieated sensitivity funetionality, the tool in its eurrent state does provide a user the 
ability undertake “trial-and-error” and “what-if ’ analysis in support of sensitivity analysis 
of derived results. Sueh analysis allows users to identify, quantify, and understand the 
bounds and limitations of the results provided by the HFSE. 

E, CHAPTER SUMMARY 

This ehapter foeused on identifying and diseussing the key mathematieal 
eonstruets needed to represent the HFSE artifaets and perform QFD operations upon 
them. The extensions to the RH model were defined and the mathematies supporting 
QFD dependeney deployment were presented and illustrated with examples. Alternative 
deployment sehemes were explored and explained. Mathematieal teehniques for 
identifying, isolating, and viewing partieular subgraphs of interest (indueed from the 
overall underlying hypergraph of the development effort) were presented. Dependeney 
valuation sehemes were offered and eompared. Finally, the topies of eonsisteney and 
subjeetivity were diseussed and teehniques for dealing with them (e.g. Coverage 
Analysis, the Analytie Hierarehy Proeess, Sensitivity Analysis, ete.) were provided. 
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V. APPLICATION OF THE OBJECT-ORIENTED 
METHODOLOGY FOR INTEROPERABILITY TO THE DOMAIN 
OF SOFTWARE DEVELOPMENT TOOLS 


A, CHAPTER OVERVIEW 

In Chapter III, the underlying ontologies needed for establishing a Federation 
Interoperability Objeet Model (FIOM) were developed. In this chapter, the focus is to 
explain how the FIOM is actually constructed using those ontologies. Section B 
describes the motivation and methodology. Section C illustrates the methodology 
through the use of an example from the software development tool domain. Section D 
discusses the steps that would be needed in order to add additional tools and development 
artifacts (such as Rational Rose and pseudo-code) to an existing software development 
tool FIOM. Section E identifies the remaining tasks that would need to be accomplished 
in order to actually embed the generated translators from the OOMI IDE into software 
development tool application add-ons. Section E points out some limitations and 
challenges of the OOMI approach. 

B. BUILDING A FEDERATION INTEROPERABILITY OBJECT MODEL 

1. Motivation for the FIOM 

[YOUN02b] defines the Object-Oriented Model for Interoperability (OOMI), 
which relies on establishing a collection of objects that represent real-world entities to 
provide interoperability between a specific set of heterogeneous systems. This collection 
of objects is called a Eederation Interoperability Object Model (EIOM). The OOMI 
approach using the FIOM overcomes numerous challenges presented by the differences 
in modeling between systems. [YOUN02b] provides a classification of these modeling 
differences, paraphrased as follows: 

• Heterogeneity of Hardware and Operating Systems: differences in the 
hardware and operating system platforms encountered when integrating 
autonomously developed systems. 

• Heterogeneity of Organizational Models: differences in the conceptual 
models used by autonomously developed systems; dissimilarities in the 
database models used, such as network, hierarchical, relational, universal, 
or object structured. 
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• Heterogeneity of Strueture: differenees in struetural eomposition, possible 
sehema mismatehes, and variations due to the presenee of implied 
information. 

• Heterogeneity of Presentation: differenees due to domain mismateh 
problems, the use of different units of measure, differenees in preeision, 
disparate data types, and different field lengths or variations in integrity 
eonstraints. 

• Heterogeneity of Meaning: differenees arising from the impreeise nature 
of natural language for eharaeterizing real-world entities. 

• Heterogeneity of Seope: differenees that arise from different perspeetives 
on what attributes a given applieation needs to eapture about the real- 
world entity being modeled. 

• Heterogeneity of Level of Abstraetion: differenees in the level and degree 
of aggregation of atomie data elements. 

• Heterogeneity of Temporal Validity: differenees in the time used by two 
models to observe or reeord the state of real-world entities. 

These modeling differenees exist in heterogeneous systems of many domains. Even 
though the OOMI was originally validated using an example from military C4I systems, 
this same model ean be applied to a different domain — the domain of software 
development tools and models. 

The OOMI was developed beeause of numerous limitations in eurrent approaehes 
to interoperability that failed to aeeount for the many differenees in modeling. 
[YOUN02b] identifies these limitations as follows: 

First, [traditional approaehes to interoperability] do not provide a means 
for resolving the eomplete speetrum of modeling differenees found among 
heterogeneous systems. Seeond, they do not provide assistanee in 
determining when different system models refer to the same entity from 
the problem domain. Third, in order to aeeess another eomponent or 
system’s state or exereise its behavior, most eurrent approaehes require the 
requesting system to utilize the provider system’s model of its state or 
behavior to aeeess its information... Fourth, most approaehes utilize a 
direet point-to-point eonversion proeess for resolving modeling differenee 
among systems viee a two-step eonversion proeess using an intermediate 
model... Fifth, most approaehes provide no or limited support to 
development of the translations required to resolve modeling differenees 
among systems. Finally, most approaehes are eoneerned only with the 
resolution of modeling differenees for information exehanged among 
systems and do not provide the eapability for resolving possible 
differenees in the signatures used to aeeess the behavior of eorresponding 
methods on different systems. 
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The FIOM provides the meehanism for subordinate model interaction in the HFSE. 
Translators generated using the FIOM provide run-time interaction between subordinate 
models. 

2, FIOM Construction Methodology 

The construction methodology used to build and use a Software Development 


Tool FIOM is illustrated in Figure 48. 



First, as discussed Chapter III, the separate tool ontologies and the federation ontology 
(of the software development tool domain) are created and represented in Protege. From 
Protege, these ontologies are automatically exported as XML schemas. The individual 
classes in the tool ontologies are exported as Component Class Representations (CCRs) 
and the classes in the overarching software development tool ontology are exported as 
Federation Class Representations (FCRs). 

Next, there are two manual interventions required before the XML 
schemas are imported into the OOMI IDL. Lirst, each of these schemas must be 
validated against the XML standard used within the OOMI IDL. During this research, 
these standards were not the same (the version of Protege used in the research produced 
schemas that were not compliant with the current W3C standard); so, manual 


155 


































modifications were made to the sehemas using an XML editor (sueh as XMLSPY® from 
Altova, Inoorporated)[LAWL03]. It should be noted that the need for this manual 
workaround may be soon eliminated beeause Protege users eontinually provide enhaneed 
and eorreeted plug-ins based on ehanging data standards. The seeond intervention is to 
modify the OOMI IDE souree eode. Unfortunately, the OOMI IDE is not yet able to 
direetly import an ECR Sehema. Instead, ECRs are eurrently hard-eoded within the 
OOMI IDE souree eode, whieh means the souree eode itself must be modified to add or 
change existing ECRs. This is aeeomplished by importing the validated ECR sehema into 
the OOMI IDE and treating it as a CCR by “Eoading” it and “Compiling” it. Save the 
eomplied elasses from that sehema in the OOMI IDE direetory speeified in the IDE’s 
createMayTestFIOMQ method. The OOMI IDE is then rebuilt and run. After eompleting 
these two manual interventions, the remaining tool ontology XME sehemas (the OCRs) 
are imported into the OOMI IDE. 

The third step in EIOM eonstruetion is to follow the methodology 
provided in Appendix A of [YOUN02b]. This methodology walks the user through how 
to use the OOMI IDE to ereate Eederation Entities (EEs) when no EEs exist and how to 
modify EEs when additional OCRs are added. The ereation of the EEs is aeeomplished 
based on eonforming to the UML inter-relationship diagrams (from Chapter III). The 
eolleeted set of all EEs eonstitute the EIOM. Onee the EIOM is ereated, the OOMI IDE 
provides sets of java skeletons (as ineomplete java elasses), whieh provide the strueture 
for the interoperability translators that perform the translation between OCRs and ECRs. 
[YOUN02b] proposes using reusable eomponent libraries to populate the holes in the 
translation skeletons. These libraries have yet to be assembled; therefore, it is left to the 
interoperability engineer to provide the missing eode for the translators. 

The final step in this proeess is to eonstruet tool add-ons and embed the 
translators within these add-ons. The add-ons provide the interfaee between the tool and 
the middleware used for data transport throughout the HESE. Currently, there is no 
automated method for eonstrueting these add-ons or embedding the translators within 
them. Within the add-ons, tool speeifie information is translated, marshaled, and un¬ 
marshaled based on the interoperability needs of the tools within the framework. 
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C. EXAMPLE OF CONSTRUCTING THE FIOM 

This section provides an example of the FIOM construction process related to the 
HFSE. Interested readers are referred to Appendix A of [YOUN02b] for additional 
details in the methodology in constructing a FIOM. First, the FCR and CCR schemas are 
automatically exported from Protege. When generating XML schemas, Protege provides 
a “Base” Schema that is common to all Protege generated schemas. The base schema 
defines the Protege namespace. The complete base schema is illustrated in Figure 49. 


<?xml version=''1.0" encoding="UTF-8"?> 

<xs:schema targetNamespace="http://protege. stanford.edu/" xmlns:xs="http://www.w3.org/2001/XMLSchema'' elementFormDefault="qualified"> 
<xs:complexType name='THING"> 

<xs:sequence/> 

<xs:attribute name="id" type="xs:ID'7> 

</xs:complexType> 

<xs:complexType name="STANDARD-CLASS"> 

<xs:sequence/> 

<xs:attribute name="id" type="xs:ID'7> 

</xs:complexType> 

<xs:complexType name="SlotType"> 

<xs:sequence> 

<xs:element name="ASSOCIATED-FACET" type-'Instance" minOccurs="07> 

<xs:element name="DIRECT-SUBSLOTS" type="lnstance" minOccurs="0" maxOccurs="-1'7> 

<xs:element name="DIRECT-SUPERSLOTS" type=’'lnstance" minOccurs="0" maxOccurs="-1'7> 

<xs:element name="DIRECT-TYPE" type="Class" minOccurs="07> 

<xs:element name="DOCUMENTATION" type=''xs:string" minOccurs="0'' maxOccurs="-17> 

<xs:element name="NAME" type="xs:string" minOccurs="07> 

<xs:element name="SLOT-CONSTRAINTS" type="lnstance" minOccurs="0" maxOccurs="-17> 

<xs:element name="SLOT-DEFAULTS" type=''xs:anyType" minOccurs="0" maxOccurs="-17> 

<xs:element name="SLOT-lNVERSE" type="lnstance" minOccurs="07> 

<xs:element name="SLOT-MAXIMUM-CARDINALITY" type="xs;integer" minOccurs="0'7> 

<xs:element name="SLOT-MINIMUM-CARDINALITY" type="xs:integer" minOccurs="07> 

<xs:element name="SLOT-NUMERIC-MAXIMUI\/l" type="xs:float" minOccurs="07> 

<xs:element name="SLOT-NUMERIC-MINIMUM'' type="xs;f]oat" minOccurs="0'7> 

<xs:element name="SLOT-VALUE-TYPE" type="xs:anyType" minOccurs="0" maxOccurs="-17> 

<xs:element name="SLOT-VALUES" type=''xs:anyType" minOccurs="0" maxOccurs="-1'7> 

</xs:sequence> 

</xs:complexType> 

<xs:element name="Slot" type=''SlotType7> 

<xs:complexType name="Slot_Override_Type"> 

<xs:sequence> 

<xs:element name="ClassName" type="xs:string7> 

<xs:element name="SlotName" type="xs:string7> 

<xs:element name="FacetName" type="xs:string7> 

<xs:element name="Value" type="xs:string'7> 

</xs:sequence> 

</xs:complexType> 

<xs:complexType name="OSValue"> 

<xs:sequence> 

<xs:element name="ClassName" type="xs:string7> 

<xs:element name="SlotName" type="xs:string7> 

<xs:element/> 

</xs:sequence> 

</xs:complexType> 

<xs:simpleType name="Symbol"> 

<xs:restriction base="xs:string’7> 

</xs:simpleType> 

<xs:simpleType name=''lnstance"> 

<xs:restriction base="xs:string’7> 

</xs:simpleType> 

<xs:simpleType name="Class"> 

<xs:restriction base="xs:string'7> 

</xs:simpleType> 

<xs:element name="SEPARATOR" type="xs:string7> 

</xs:schema> 


Figure 49 Protege Base XML Schema 
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The Protege Base XML Schema defines the metadata for the Protege knowledge base; 
notice the use of classes, slots, and facets. 

The next item to be automatically generated from Protege is the FCR 
schema representation of the Software Development Tool Ontology. Recall from 
Chapter III (Figure 34) that the entire software development tool ontology produced for 
this FIFSE research consisted of approximately 40 classes. The XML Schema in Figure 
50 is one small excerpt of that ontology and includes only two classes (i.e. the 
Requirement class and Specification class). 


<xs:schema elementFormDefault- ’qualified" targetNamespace="http://protege. stanford.edu/" 
xmlns:xs="http://www.w3.org/2001/XMLSchema"> 

<xs:include schemaLocation="file:///C:/Program_Files/Protege-2000/base.xsd"> 

</xs:include> 

<xs:complexType name="RequirementType"> 

<xs :com pi exCo nte nt> 

<extension base="THING"> 

<xs:sequence> 

<xs:element fixed="STANDARD-CLASS" maxOccurs="0" minOccurs="0" name="METACLASS" type="xs:string'7> 
<xs:element minOccurs="0" name="Name" type="xs:string7> 

<xs:element minOccurs="0" name="Tag" type="xs:string7> 

<xs:element minOccurs="0" name="Text" type="xs:string'7> 

<xs:element maxOccurs="0" minOccurs="0" ref="SEPARATOR"/> 

</xs:sequence> 

</extension> 

</xs:complexContent> 

</xs:complexType> 

<xs:complexType name="SpecificationType"> 

<xs :com pi exCo nte nt> 

<extension base="THING"> 

<xs:sequence> 

<xs:element fixed="STANDARD-CLASS" maxOccurs="0" minOccurs="0" name="METACLASS" type="xs:string'7> 
<xs:element minOccurs="0" name="Name" type="xs:string7> 

<xs:element maxOccurs="unbounded" minOccurs="0" name="Required_By" type="xs:string7> 

<xs:element minOccurs="0" name="Tag" type="xs:string7> 

<xs:element minOccurs="0" name="Text" type="xs:string'7> 

<xs:element maxOccurs="0" minOccurs="0" ref="SEPARATOR"/> 

</xs:sequence> 

</extension> 

</xs:complexContent> 

</xs:complexType> 

<xs:complexType name="tool_reqt_specOntologyType"> 

<xs:sequence> 

<xs:element maxOccurs="unbounded" minOccurs="0" name="Slot" type="SlotType7> 

<xs:element maxOccurs="unbounded" minOccurs="0" name="SlotOverride" type="Slot_Override_Type7> 

<xs:element maxOccurs="unbounded" minOccurs="0" name="Requirement" type="RequirementType7> 

<xs:element maxOccurs="unbounded" minOccurs="0" name="Specification" type="SpecificationType"/> 

</xs:sequence> 

</xs:complexType> 

<xs:element name="tool_reqt_specOntology" type="tool_reqt_specOntologyType"> 

</xs:element> 


Figure 50 Software Development Tool XML Schema Excerpt 

As discussed above in Section B, this FCR schema must be manually manipulated so that 
it can be validated against the current XML standard [LAWL03]. It is imported into the 
OOMI IDE, treated as a CCR to generate compiled java classes of the schema, and then 
embedded within the OOMI IDE as an FCR. The OOMI IDE itself is then rebuilt and 
rerun before importing the tool OCRs. 
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The tool CCRs are also automatically generated from Protege and as in the 
case of the FCR, are manually updated to become compliant with the current XML 
standard. Figure 51 and Figure 52 illustrate small excerpts of the complete XML 
schemas from the SEATools ontology and Requisite®Pro ontology, respectively. 


<xs:schema elementFormDefault="qualified" targetNamespace="http://protege. stanford.edu/" 
xmlns:xs="http://www.w3.org/2001/XMLSchema"> 

<xs:include schemaLocation="file:///C:/Program_Files/Protege-2000/base.xsd"> 

</xs:include> 

<xs:complexType name="DataFlowComponentType"> 

<xs:complexContent> 

<extension base="THING"> 

<xs:sequence> 

<xs:element fixed- 'STANDARD-CLASS" maxOccurs="0" minOccurs- '0" name="METACLASS" type="xs:string"/> 
<xs:element minOccurs="0" name="laber' type="xs:string"/> 

<xs:element maxOccurs="0" minOccurs="0" ref="SEPARATOR"/> 

</xs:sequence> 

</extension> 

</xs;complexContent> 

</xs:complexType> 

<xs:complexType name="EdgeType"> 

<xs:complexContent> 

<extension base="DataFlowComponentType"> 

<xs:sequence> 

<xs:element fixed="STANDARD-CLASS" maxOccurs="0" minOccurs="0" name="METACLASS" type="xs:string"/> 
<xs:element minOccurs="0" name="edgelD" type="xs:integer"/> 

<xs:element maxOccurs="0" minOccurs="0" ref="SEPARATOR"/> 

</xs:sequence> 

</extension> 

</xs:complexContent> 

</xs:complexType> 

<xs:complexType name="VertexType"> 

<xs:complexContent> 

<extension base="DataFlowComponentType"> 

<xs:sequence> 

<xs:element fixed- 'STANDARD-CLASS" maxOccurs="0" minOccurs- '0" name="METACLASS" type=''xs:string''/> 
<xs:element maxOccurs=’'unbounded" minOccurs="0'' name="finishWithinReqmts" type=''xs:string''/> 

<xs:element minOccurs=''0’' name="formalDesc" type="xs:string''/> 

<xs:element minOccurs="0’' name="informalDesc" type="xs:string"/> 

<xs:element maxOccurs- 'unbounded" minOccurs="0'' name="mcpReqmts" type="xs:string''/> 

<xs:element maxOccurs="unbounded" minOccurs="0'' name="metReqmts’' type="xs:string''/> 

<xs:element maxOccurs- 'unbounded" minOccurs="0'' name="mrtReqmts’' type="xs:string''/> 

<xs:element maxOccurs- 'unbounded" minOccurs="0'' name="periodReqmts" type=’'xs:string''/> 

<xs:element maxOccurs="unbounded" minOccurs="0'' name="specReqmts" type="xs:string''/> 

<xs:element maxOccurs- 'unbounded" minOccurs=''0'' name="triggerReqmts" type="xs:string"/> 

<xs:element minOccurs=''0" name="vertexlD" type="xs:integer"/> 

<xs:element maxOccurs="0" minOccurs="0" ref="SEPARATOR''/> 

</xs:sequence> 

</extension> 

</xs:complexContent> 

</xs:complexType> 

<xs:complexType name="seatools_specOntologyType"> 

<xs:sequence> 

<xs:element maxOccurs="unbounded" minOccurs="0" name="Slot'' type=''SlotType"/> 

<xs:element maxOccurs="unbounded" minOccurs="0" name="SlotOverride'' type="Slot_Override_Type"/> 

<xs:element maxOccurs="unbounded" minOccurs="0" name="DataFlowComponent" type="DataFlowComponentType"/> 
<xs:element maxOccurs="unbounded" minOccurs="0" name="Edge" type="EdgeType"/> 

<xs:element maxOccurs="unbounded'' minOccurs="0" name="Vertex" type="VertexType"/> 

</xs:sequence> 

</xs:complexType> 

<xs:element name=''seatools_specOntology" type="seatools_specOntologyType"> 

</xs:element> 


Figure 51 SEATools XML Schema Excerpt 
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<xs:schema elementFormDefault="qualified" targetNamespace="http://protege. stanford.edu/" xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
<xs:include schemaLocation="file:///C:/Program_Files/Protege-2000/base.xsd"> 

</xs:include> 

<xs:complexType name="RequirementType"> 

<xs:complexContent> 

<extension base="THING"> 

<xs;sequence> 

<xs;element fixed="STANDARD-CLASS" maxOccurs="0" minOccurs="0" name="METACLASS" type="xs:string"/> 
<xs:element minOccurs="0" name="Name" type="xs:string7> 

<xs:element minOccurs="0" name='Tag" type="xs:string7> 

<xs;element minOccurs="0" name='Text" type="xs:string"/> 

<xs;element maxOccurs="0" minOccurs="0" ref="SEPARAT0R"/> 

</xs:sequence> 

</extension> 

</xs:complexContent> 

</xs:complexType> 

<xs:complexType name="reqpro_reqtOntologyType"> 

<xs:sequence> 

<xs:element maxOccurs="unbounded" minOccurs="0" name="Slot" type="SlotType"/> 

<xs:element maxOccurs="unbounded" minOccurs="0" name="SlotOverride" type="Slot_Override_Type'7> 

<xs:element maxOccurs="unbounded" minOccurs="0" name="Requirement" type="RequirementType7> 

</xs:sequence> 

</xs:complexType> 

<xs:element name="reqpro_reqtOntology" type="reqpro_reqtOntologyType"> 

</xs:element> 

</xs:schema> 

</xs;schema> 


Figure 52 Requisite®Pro XML Schema Excerpt 

After importing the CCRs into the OOMI IDE, the FIOM is constructed 
by defining Federation Entity Views (FEVs) and Federation Entities (FEs). FEVs 
establish the one to one relationship between a particular FCR and CCR pair. FEs are 
groupings of FEVs that represent the complete set of representations of the same real- 
world entity between all the systems in a federation. Figure 53 illustrates the 
“requirement” Federation Entity for the software tool FIOM consistent with the imported 
FCR and CCR XMF Schemas in Figure 50 and Figure 52, respectively. 
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requirement 
r-- 


requirementViewI 


requirementViewlFCR 



Figure 53 Requirement Federation Entity (FE) 

Note that the class representation in the CCR and FCR are identical. As [YOUN02b] 
points out, this is typical in the FIOM construction process; the initial FCR in an FE is 
constructed so that it mimics the first CCR that is introduced in the model. The complete 
set of FEs form the EIOM. 


161 


























































D, EXTENDING THE FIOM TO ACCOUNT FOR ADDITIONAL TOOLS 

Given an established FIOM, an important question to be answered is how this 
FIOM is then modified and extended when additional tools are added to the framework. 
Sueh extensions are aeeomplished by undertaking the ontology addition/modifieation 
proeess defined in Chapter III (end of Seetion B) and then modifying the FIOM in 
aeeordanee with [YOUN02b], Appendix A. An important eoneept during this proeess is 
to establish a balanee between the granularity available in the tool deseription of the 
software artifaet and the desired granularity of the set of holistie relationships required 
from the HFSE. As an example to illustrate the issues involved in sueh extensions, 
eonsider the possible addition of Rational Rose® and a set of pseudo-eode to an already 
eonstrueted FIOM in the HFSE. 

1. Addition of Rational Rose® Example 

Given an already established HFSE FIOM (perhaps consisting of SEATools and 
Requisite®Pro objects) adding the UML modeling tool. Rational Rose, requires a number 
of steps. First, using the methodology of Chapter III, an ontology is created that defines 
the Rose artifacts to be represented within the HFSE. In the case of Rose, the engineer 
must determine what level of artifact granularity is available and what level of granularity 
is desired within the HFSE. Rose provides a COM extensibility interface that allows the 
engineer access to objects within a Rose model. The level of granularity varies between 
the entire model itself (a single .mdl file) and the elements within that model (e.g. the 
object representations of the use case actors, model views, class diagram classes, 
sequence diagram activities, etc.). For the sake of this example, assume that the engineer 
wishes to reference the specific elements of a Rose model (as opposed to simply the 
model itself). The user accesses these “Model Elements” through the Rose Extensibility 
Interface (see Figure 54). 
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Figure 54 Rational Rose Extensibility Interface (from [ROSE02]) 

After the user ereates an ontology and UML representation of the Rose elements, he must 
then establish how this UML representation interacts with the already existing UML 
defined relationships of the FIOM. The FIOM UML description is then modified to 
account for the additional objects in the federation. Just modifying the UML description 
is not of course sufficient; the FIOM itself must be modified. This is accomplished by 
exporting the XML schema related to the Rose objects (the Rose CCR), importing that 
CCR into the OOMI IDE, building new FEVs to account for the new CCR, and then 
modifying the relationships between EEVs to update the EEs [YOUN02b]. At that point, 
the OOMI IDE generates new translators that are then re-embedded into all the tool add¬ 
ons throughout the HESE. Also, the engineer must construct an add-on for Rose so that it 
can interact with the other tools in the HESE. 

2. Addition of Pseudo-Code Example 

Now consider a second example of wanting to include portions of pseudo-code 
into the HESE. The issue associated with granularity becomes particularly problematic. 
Also problematic is how the artifacts are stored and accessed by the HESE. Assume that 
the user has defined several algorithms using pseudo-code along the lines of those shown 
in Eigure 55 and Eigure 56. 
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Insertion-Sort(^ ) 

1 for 7 <— 2 to length[A\ 

2 do key <— Alj] 

3 > Insert A[j] into the sorted sequence ^[1 ..7 -1]. 

4 /^ 7 -l 

5 while i > 0 and A[j] > key 

6 do A{i +1] <— 

7 i ^— i — \ 

8 A[i +1] <— key 

Figure 55 Insertion-Sort Algorithm Pseudo-Code (from [CORM91]) 


Merge-Sort(A, p, r) 

1 \f p <r 

2 then q 

3 Merge - Sort(y4, 

4 Merge-Sort(y4, q + \, r) 

5 Merge(^, p, q, r) 

Figure 56 Merge-Sort Algorithm Pseudo-Code (from [CORM91]) 

The issue now beeomes how these software development artifaets (pseudo-eode 
algorithms) are ereated, stored, and maintained. Assuming a worst ease in whieh the 
pieees of eode are simply seribbled on separate pieees of paper, the engineer must 
artifieially ereate an eleetronie deseription of these artifaets that ean be exploited by the 
HFSE. This artifieial deseription might be as simple as an eleetronie CSV file that lists 
the two major artifaets (see Table 27). 


ID 

Name 

Description 

IS 

Insertion-Sort Algorithm 

An algorithm that uses insertion to sort items. 
Effieient for a small number of elements. 

MS 

Merge-Sort Algorithm 

A reeursive algorithm that employs a divide-and- 
eonquer approaeh to sorting. 


Table 27 Large Granularity Pseudo-Code CSV File 


Again, granularity beeomes an issue. The engineer might need to speeify the artifaets to 

a finer level of granularity in order to link them appropriately to other objeets in the 
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HFSE (e.g. to specific lines of code). In such a case, the CSV file might look like the one 
in Table 28. 


ID 

Name 

Description 

IS 

Insertion-Sort Algorithm 

An algorithm that uses insertion to sort items. 
Efficient for a small number of elements. 

ISl 

Insertion-Sort Fine I 

for 7 <— 2 to length{A\ 

IS2 

Insertion-Sort Fine 2 

do key <— A{j^ 

IS3 

Insertion-Sort Fine 3 

> Insert A{j^ into the sorted sequence ^[I ..7 -1]. 

IS4 

Insertion-Sort Fine 4 

/ <— 7 -1 

IS5 

Insertion-Sort Fine 5 

while i > 0 and ^[ 7 ] > key 

IS 6 

Insertion-Sort Fine 6 

do A\i +1] <— H[z] 

IS7 

Insertion-Sort Fine 7 

i ^—i 

IS 8 

Insertion-Sort Fine 8 

A\i +1] <— key 

MS 

Merge-Sort Algorithm 

A recursive algorithm that employs a divide-and- 
conquer approach to sorting. 

MSI 

Merge-Sort Fine 1 

p <r 

MS2 

Merge-Sort Fine 2 

then ^ [( 7 > + r) / 2 J 

MSS 

Merge-Sort Fine 3 

Merge-Sort(H, p, q) 

MS4 

Merge-Sort Fine 4 

Merge-Sort(H, q + \, r) 

MS5 

Merge-Sort Fine 5 

Merge(H, p, q, r) 


Table 28 Fine Granularity Pseudo-Code CSV File (after [CORM91]) 


The amount of effort that the engineer should spend to artificially create an electronic 
description of the artifacts must be carefully weighed against the potential payoff in long¬ 
term accessibility, visibility, and maintainability provided by the electronic description as 
well as the potential pay-off associated with having these artifacts linked through QFD 
dependencies to the other artifacts in the HFSE. 

Once an electronic representation of the artifacts is established, the engineer is 
then free to add them to the HFSE just as he would any other artifacts: create an ontology 
description of the artifacts, export that description as an XMF schema, update the FIOM, 
generate new translators, create an add-on that interfaces the pseudo-code CSV file, and 
re-embed the translators in the application add-ons. One issue remains, however, and that 
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is that the engineer must manually (and eontinually during the entire lifeeycle) maintain 
proper eonfiguration management between the eleetronie deseription of the artifaets and 
the real artifacts scribbled on pieces of paper. 


E. CREATING THE TOOL ADD-ONS 

The final step in applying the OOMI methodology to the HFSE is to construct 
tool add-ons and embed the translators within these add-ons. These add-ons provide the 
interface between the tool and the middleware used for data transport throughout the 
HFSE. Neither this dissertation research, nor the research presented in [YOUN02b] 
validated this major step of the OOMI approach. While it does not appear to be 
particularly problematic, this step does represent additional overhead when adopting the 
OOMI approach within the HFSE. Considerations in constructing the add-ons include 
the following: 

• The add-on must interface with both the tool API and the HFSE 
middleware mechanisms. 

• The translators within the add-ons should be easy to replace and update. 

• The tool add-on should be constructed in such a way as to anticipate future 
upgrades of the tool while minimizing potential changes to the add-on. 

Validating this step of the research is considered an area of future research (see Chapter 

IX). 

F. LIMITATIONS OF THE OOMI APPROACH TO PROVDING 

INTEROPERABITIY WITHIN THE HFSE 

A significant advantage of the OOMI approach is that it reduces the number of 
potential translations needed between heterogeneous systems {2n versus n ). This is an 
important consideration given the number of potential tools that a developer might use 
over the lifetime of a software development effort. Another advantage is the incremental 
nature of the approach; the developer can select how many (or how few) different tools to 
include in the HFSE and how many (or how few) artifacts to include. However, despite 
these advantages there are a number of limitations in the approach that should be 
considered. 
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1. The Intra-lingual Concept 

In previous natural language translation researeh, intra-lingual approaehes have 
been attempted without sueeess. The reasons for these failures inevitably stemmed from 
the size and the eomplexity of the task. It was just too diffieult to establish an intra¬ 
lingua that eould aeeount for all of the semantie differenees posed by different eulturally 
influeneed languages. Having pointed out this limitation, there is some reason to believe 
that establishing an intra-lingua for heterogeneous eomputer systems might be more 
sueeessful. These reasons inelude the more manageable size and eomplexity of the 
problem and the existenee of tighter bounds on the semantie differenees between 
eomputer systems than those that exist in eulturally defined natural languages. However, 
it remains to be validated whether the approaeh is manageable when the number of 
heterogeneous systems and artifaets eontinues to inerease. 

2. Scalability 

As previously diseussed, adding additional tools to an ontology or a FIOM is not 
a simple additive proeess. There is a lot of work that must take plaee to reorganize the 
internal strueture of the ontology and FIOM to aeeommodate new tools. The question 
then beeomes one of sealability. At what point in the proeess does the internal 
reorganization required to aeeommodate a new tool make the approaeh to beeome 
infeasible? This issue is eonsidered an issue for future researeh (see Chapter IX). 

3. Ontologies and FIOMs are Difficult to Build 

Ontologies are hard to build, espeeially in an automated way. Construetion takes 
a great deal of time and effort beeause the same issues of understandability, identified in 
this dissertation as motivation for the HFSE, exist in the eonstruetion of ontologies and 
later in eonstruetion of the FIOM. It is diffieult and time eonsuming to understand and 
eomprehend the previous efforts of an ontology/FIOM engineer before making 
signifieant progress in extending an ontology or FIOM. While Young’s OOMI model is 
an attempt to represent ontologies in an ineremental and eomputationally useful way, 
addition work is needed to make the overall approaeh more pragmatie. 
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G. SUMMARY 

This chapter illustrates through the use of examples how a HFSE FIOM is eonstrueted 
and used given ontology deseriptions of HFSE artifaets. The ehapter also provides an 
overview of the tasks required when adding additional tools to an HFSE FIOM and 
diseusses the limitations of the approaeh. 
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VI. THE HOLISTIC FRAMEWORK FOR SOFTWARE 
ENGINEERING (HFSE) 


A. THE HFSE 

The HFSE is both a methodology and a model (with tool support) for integrating 
two or more software development tools so that they provide a holistie view of software 
development artifacts created and used during a software development lifecycle. This 
chapter explains how to apply the HFSE to integrate a set of software development tools, 
how to extend the HFSE to include additional tools, and how to use the HFSE to obtain 
user defined holistic views of the software development process. 


B, APPLYING THE HFSE TO ESTABLISH INTEROPERABILITY OF 

SOFTWARE ENGINEERING PROCESS MODELS 

1. Identifying The Project Schema 

The first step in applying the HFSE is to identify the project schema of the 
particular software development effort. As defined in Chapter IV, a project schema is an 
abstract view of the software development process. Annotated as a directed hypergraph, 
the nodes of the project schema represent different types of software development 
artifacts (components) while the hyperedges of the schema represent development 
activities (steps). Each of the nodes and edges is later decomposed into the instantiated 
atomic components and atomic steps of the development effort. The engineer creates the 
project schema by identifying all of the different types of software development artifacts 
created in their particular development process. Next the engineer identifies the activities 
that are used to produce these artifacts. Finally, the engineer connects these artifacts and 
activities into a process flow diagram that mirrors the software development process 
actually being used. 

2. Establishing the Tool Ontology 

Once the engineer has created the project schema, the next step is to apply the 
techniques described in Chapter III to create a foundational ontology that can be used to 


169 



unify the software development tools that produee the artifacts portrayed in the project 
schema. 

3. Constructing the FIOM 

The third step is to apply the techniques described in Chapter V to use the 
federation ontology to construct a FIOM of the software development domain. The 
individual tool ontologies provide the separate component representations used to 
construct the FIOM. The data from these tools (data representing the software 
development artifacts) is the data for which translators are established. 

4. Establishing Communication Mechanisms 

The fourth step in establishing the HFSE is to embed the translators created in the 
FIOM construction process into a communications mechanism so that data exchange and 
joint task execution is achieved. Middleware (such as CORE A) is one such candidate 
communications mechanism and potentially provides dynamic flexibility within the 
HFSE. However, the communications mechanism need not be as complex as a dynamic 
middleware implementation. Eor instance, the mechanism used in this dissertation to 
demonstrate theoretical feasibility of the HESE was to use a simple static file import 
mechanism. The complexity of the communications mechanism should be selected on the 
basis of the complexity of the software development being modeled. A development 
effort involving numerous concurrent activities, customers, developers, architects, and 
programmers may require a more complex communications mechanism than one 
implementing a light, agile software development process. 

5. Identifying Dependencies and Artifact Correlations 

The final step in establishing the HESE using the techniques described in Chapter 
IV is to create QED dependencies, artifact (component) correlations, and to deploy the 
dependencies throughout the software development effort. 

B, EXTENSIONS 

1. Extending the FIOM with Additional Software Development Tools 

Once a FIOM has been created that integrates a selected set of software 
development tools, the FIOM can be extended to incorporate new tools and remove 
obsolete tools. The techniques for adding tool representations are discussed in Chapter V 
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and in greater detail in [YOUN02b]. The basie eoneept is that the new Component Class 
Representations (CCRs) of the new tool are integrated into the existing Objeet Model of 
the tool Federation. The Federation Entities (FEs) are modified to aeeommodate the 
additional representations. Additional translators are eonstrueted as needed. 

2. Extending the HFSE 

Extending the HESE eonsists of two main steps: modifying the projeet sehema 
and then integrating the updated EIOM into the framework. The HESE projeet sehema is 
simply redrawn (or modified) to aeeommodate the additional artifaets or the removal of 
artifaets. Next the undated EIOM is used to register the 

3. Adding Dependencies 

Adding additional dependeneies to the HESE is more straightforward than adding 
additional tools to the EIOM. New dependeneies are simply ereated at any point of the 
development effort. Initial values for the dependeney are established and the dependeney 
values are deployed both upstream and downstream in the development effort. 

C. FOCUSED DEVELOPMENT USING "SLICES" 

1. Dependency Threshold 

The HFSE allows the engineer to isolate partieular subsets of software 
development effort as a smaller subgraph of the overall hypergraph that represents the 
entire development effort. Onee sueh “shoe” is indueed by the Dependeney Threshold 
View. For a particular dependency, the Dependency Threshold View is useful if the 
engineer wants to identify which components are associated with the greatest (or least) 
dependency values, for example the greatest risk, the least difficulty, etc. In each of these 
cases, the engineer would have defined that particular dependency (risk and difficulty) 
and assigned values to the dependency and deployed the dependency throughout the 
development effort. The Dependency Threshold View then provides a means of isolating 
important information from the remaining noisy data in the development effort. 

2. Component Tracing 

The second way in which the HFSE allows the engineer to isolate interesting 
subgraphs of the development hypergraph is through the Component Trace View. The 
Component Trace View is useful because it allows an engineer to identify all connected 
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components of a particular component of interest. For example, if the engineer wanted to 
modify a particular program module, he could use the Component Trace View to identify 
all connected components that influenced (or are influenced by) that particular module. 
Furthermore, because the correlations between components in QFD matrices all have 
particular values, the engineer can specify the degree of relationship he is interested in 
isolating. 

3, Potential Application of Risk-Induced Slices 

One possible future research thread is to examine the benefits of using the HFSE 
to extract a risk-induced slice of the development effort and to then focus developmental 
resources on that slice. This potentially would improve the Software Development Life 
Cycle in the following three ways: 

a. Greatest Risk Slices 

First, the HFSE aims to improve prototyping efforts by allowing the 
designer to focus only on those aspects of the design that represent the greatest 
uncertainty and/or greatest risk to project success. It should be possible to extract a 
"slice" of the entire dependency graph so that effort is not wasted on aspects which are 
already well defined, understood, and/or successfully implemented in previous versions. 
This will make the development effort more efficient and economic. Also, it may be 
possible to make this become a prescription rule rather than a filtering constraint, so that 
only the parts of the graph in (or near) the designed slice are constricted in the system to 
begin with. Building the entire graph and then “slicing” it may waste a lot of human 
effort. 

b. Change Knock-on Effects 

Secondly, it will be possible to identify and isolate the impact of 
individual changes on other dependent parts of the software development effort. Because 
all the software artifacts are linked together by a relational hypergraph, after making a 
single change to a single artifact it will be possible to have immediate visibility of all 
other artifacts that require modification due to that change. It will also be possible to 
have immediate visibility of the customer's view of the change since their priorities have 
been "deployed" (by SQED) throughout the design. A possible implication of this is to 
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support cost-benefit analysis to determine if the proposed modification be with the effort 
— or whether the effort ean tolerate “the implied eost” of the modifieation. 
c. Safety Certification 

Finally, we ean leverage the extended Evolution Model by identifying the 
total effeet of individual ehanges to safety eritieal portions of the software. Produeing 
reliable software is an expensive and time-eonsuming endeavor. Mueh of the expense 
and time is related to identifying all "knoek-on" effeets when modifying eritieal parts of 
the software and then re-eertifying the software after aceessing these knoek-ons. The 
extended Software Evolution model will make it possible to identify all of these "knoek- 
on" effeets quieker and more metieulously by relying on automated methods. 

D. CHAPTER SUMMARY 

This ehapter provided a high level summary of the Holistie Eramework for 
Software Engineering. Speeifieally, it explained how to apply the HESE to integrate a set 
of software development tools, how to extend the HESE to inelude additional tools, and 
how to use the HESE to obtain user defined holistie views of the software development 
proeess 
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VII. EXTENSIONS TO THE COMPUTER AIDED SOFTWARE 
EVOLUTION SYSTEM (CASES) 

A. CHAPTER OVERVIEW 

As presented in Chapter II, the Computer Aided Software Evolution System 
(CASES) was developed in support of Ham’s RH model of software evolution 
[HARN99o]. Speeifieally, CASES was developed by [EEHC99] to demonstrate the 
feasibility of providing tool support for the RH model. In order to support the work in 
this dissertation, the CASES tool was further extended to inelude needed funetionality for 
the HESE and the QED extensions presented in Chapters IV and VI. As part this 
dissertation, a set of UME use eases was developed that elarify how CASES is to be used 
and how it internets with other tools in support of the HESE (see Appendix A). The effort 
to extend CASES with QED funetionality was speeifioally undertaken by Clomera 
[CEOM03] and this ehapter presents and summarizes the key eontributions of his work in 
developing a software evolution support tool to support the eonstmction of the HESE. 
Readers interested in additional detail of the CASES extensions developed in support of 
this dissertation are referred to [CEOM03] and Appendix A. 

This ehapter provides an overview of the extensions made to CASES version 1.1 
to ereate CASES version 2.0. Seetion B summarizes the results of the effort to provide 
graphie funetionality for software development projeet sehema ereation. Seetion C 
presents the details of the QED funetionality embedded in the tool so that artifaet 
dependeneies ean be ereated, traeked, and deployed. Einally, Seetion D summarizes the 
work that provides user defined views so that dependeney data ean be isolated, examined 
and reasoned about. The major contributions provided by [CEOM03] in support of this 
dissertation allow a software engineer to (1) design a custom software evolution model 
through the use of the CASES GUI, (2) input, modify, and analyze dependency 
characteristics between software artifacts within a QED framework, and (3) make 
decisions based upon views of dependency information. 
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B. GRAPHICALLY DEFINING A SOFTWARE DEVELOPMENT PROJECT 

SCHEMA 

1. The Project Schema in CASES version 1,1 

In her Masters Thesis [LEHC99], Le developed the automated software evolution 
tool known as the Computer-Aided Software Evolution System (CASES version 1.1) in 
support of Ham’s Relational Hypergraph (RH) Model of software evolution. 
CASESvl.l was developed using object-oriented tools, Java Development Kit (JDK) 
1.1.7, Swing 1.0.3, under the Visual Cafe version 3.0 environment (see Eigure 57). 
CASES assists the software engineer in performing software evolution activities and 
allows the engineer to better control and manage the software evolution process. The 
tool provides five functions related to the activities of software evolution. These are step 
refinement, project evaluation, constraint management, personnel management, and step 
management. Additionally, CASES provides five functions related to software evolution 
components: component management, component traceability, configuration 

management, dependency management, and inference mle management. 



Figure 57 CASESvl.l New Project Screenshot 

CASESvl.l allows the user to define steps and components tailored to a specific 
single software development methodology: the evolutionary process model (previously 
illustrated in Chapter II, Eigure 6). CASES manages and controls all of the activities that 
change a software system and the relationships among these steps and components. 
CASESvl.l was the first tool to support the practicality of the RH model. However, the 
utility of the tool was constrained by the reliance on a text and menu driven functionality 
tied to a single specific software development model. In version 1.1 of CASES, the 
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software engineer inputs information related to their software development process 
through a series of text and menu driven dialogs (see Figure 58). 



Figure 58 CASESvl.l Project Schema Creation Dialog 

While not only laborious, this approach obfuscates the evolutionary linkages within 
lengthy textual strings. One of the objectives in the research conducted by [CLOM03] 
was to improve Le’s work by providing an intuitive, graphically based interface so that 
the software engineer could easily define project schemas related to their own specific 
software development process. 

2, The Project Schema in CASES version 2,0 

In CASES version 2.0, [CLOM03] improves upon version 1.1 by providing an 
interactive GUI by which software engineers can construct and tailor a specific software 
development project schema. The schema is no longer necessarily tied to the 
evolutionary prototyping model of software development. The engineer is free to create 
components and steps that represent the artifacts and activities actually used in the 
development effort, artifacts actually created in other software development tools. Figure 
59 illustrates the CASESv2.0 project schema drawing pane in which an engineer is 
graphically depicting an abstraction of their particular software development process by 
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identifying unique eomponents (types of software artifaets) and eonneeting those 
eomponents with development steps (types of aetivities leading to the generation of 
components). 



Figure 59 CASESv2 Project Schema Creation Process 

In this particular case the engineer uses a point-and-click interface to create the project 
schema. As the engineer creates new components and steps, the components and steps 
are automatically given a unique identifier name. The individual components and steps 
are then specialized based on the specific attributes of the development process to 
complete the project schema. 

As an example, consider a simple software development life-cycle in which the 
main development artifacts include the following; 

• Customer requirements, 

• Questions and answers (based on customer-developer dialog about 
the requirements), 

• Software specifications, 

• Code, and 

• Feedback (from the customer based on validation testing of the 
code). 

The project schema for this particular software process is illustrated in Figure 60. 
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Figure 60 CASESv2 Completed Project Schema 

Note that in this schema, the different types of components (the different types of 
software development artifacts) are abstracted as individual vertices in a directed graph 
and the steps (the activities in the development effort) are abstracted as directed edges in 
the graph. This easy to understand abstraction simplifies the textual based project 
schema format used in CASESvl. 1. Notice also that this schema bears no resemblance to 
the evolutionary prototyping model required in version 1.1, the engineer was able to 
create a project schema tailored to and matching their own unique software development 
process. 

It is notable, that while the use of the evolutionary prototyping model is not 
required in CASESv2.0, there is no reason a software engineer could not create that 
particular schema if desired. The schema created in Eigure 61 illustrates exactly that — 
the IBIS evolutionary prototyping model (originally illustrated in Chapter II, Eigure 6) 
implemented in CASESv2. 


179 







































Figure 61 IBIS Evolutionary Process Model in CASESv2 

Providing a project schema creation GUI is a significant enhancement over 
version 1.1. The GUI provides the software engineer an easy to use, intuitive interface 
for modeling within CASES the actual artifacts and activities used in particular software 
development efforts. Next, consider the CASES enhancements related to QED that allow 
the engineer to decompose these high-level component and step abstractions into atomic 
components and steps so that the engineer can deploy particular defined dependencies 
throughout the whole of the development effort. 

C. EMBEDDING QED INTO CASES 

There are three main enhancements needed to CASESvl.l in order to embed the 
QED functionality required to support the HFSE. First, CASES needed a means of 
capturing user specified dependencies (and attributes of those dependencies). Second, 
CASES needed a means of registering the abstract components of the project schema 
(e.g. requirements, specifications, code, etc.) with specific decomposed, instantiated 
component data (e.g. atomic components such as Requirement number 1.3, variant 2, 
version 3). Third, CASES needed to provide the engineer the ability to display and 
modify QED matrices implied by the registered data. 
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1, QFD Dependencies 

As defined in Chapter IV, QFD Dependencies are the set of specialized 
relationships that are “deployed” from one set of components to another. Examples of 
QFD Dependencies include risk, customer priority, difficulty of implementation, cost of 
implementation, requirement stability, safety, security, etc. In CASESv2.0 QFD 
Dependencies begin with the use of a Dependency creation dialog (see Figure 62). The 
engineer creates dependencies by left “clicking” the “dependency” button on the CASES 
toolbar. The engineer inputs the dependency name, description, type, value range, 
default value and origin. 



Figure 62 CASESv2 Dependency Creation Dialog 

The name provides a short name for identifying one dependency from another. The 
description provides the engineer the opportunity to record particular details of a 
dependency so that others can later understand the context of the dependency. The type 
can be selected from “risk”, “safety”, and “parent-child.” In CASESv2.0 the “type” field 
does not provide any actual functionality; but is provided as a possible future extension in 
which specific, pre-defmed dependency type attributes can be associated at run-time with 
particular instantiated dependencies. The value range is also provided as a feature for 
future extension and currently assumes a real value range of 0 to 9. Future extensions of 
value ranges could account for step functions, integer values, or Boolean values. The 
default value is used to initialize the dependency values in the QFD matrix upon the first 
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use of a dependency. The “origin” of the dependency must be set to a component in the 
project schema and represents the source from which the dependency value is generated. 
For instance, a dependency of “Specification Difficulty” might use the “Specifications” 
component as the origin since it is likely that the difficulty value will be generated by 
considering the difficulty of implementing each specification. This origin is used as the 
basis to perform upstream and downstream calculations (discussed in Chapter IV) based 
upon that component. 

2. Component Data Import 

The next major QFD extension to CASES is the ability to import real artifact data 
from external software development tools. In CASESvI.I the user was provided the 
functionality of opening an external software development tool (e.g. Microsoft Word, 
CAPS, MS Excel, Netscape, Notepad). Those tools were then used to create separate 
individual files for each atomic component. Eor example in [HARN99c], an individual 
text file “/c4idata/1.2/requirements/c4i.gui_2.5.req.text.txt” was created for this variant 1, 
version 2, requirement 2.5, C4I GUI requirement: 

The dynamic output graphic interface must provide the function of 

monitoring the target and missile intersection point. 

This individual text file was then associated within CASES as a single reference to the 
atomic component: Rl.2-2.5. While working within CASES, the engineer either had to 
remember what this reference referred to or had to create a separate listing of all the files 
and individual data in order to laboriously identify the linkages between components. As 
an example, consider Eigure 63 and the effort required to obtain an intuitive feel for how 
Rl.2-2.5 was arrived at during the requirement analysis step. The engineer would 
probably have to have a minimum of four separate files open at the same time (related to 
the references i?i.2-2. A Rl.1-1.6,11.2-3, VT-Rl.2-2.5). 
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Requirement analysis step: s-Rl.2 

(Rl.2-1 s-Rl.2-1 (Rl.l, 11.2-2,11.2-3, VT-Rl.2-1)) 

(Rl.2-1.1 <r- s-Rl.2-1.1 (Rl.1-1,11.2-2.1,11.2-2.2, VT-Rl.2-1.1)) 

(Rl.2-1.2 <r- s-Rl.2-1.2 (Rl.1-1,11.2-2.3,11.2-3.1, VT-Rl.2-1.2)) 

(Rl.2-2 ^ s-Rl.2-2 (Rl.1-1,11.2, VT-Rl.2-2)) 

(Rl.2-2.1 <r- s-Rl.2-2.1 (Rl.1-1.1,11.2-3, VT-Rl.2-2.1)) 

(Rl.2-2.2 ^ s-Rl.2-2.2 (Rl.1-1.2,11.2-3, VT-Rl.2-2.2)) 

(Rl.2-2.3 ^ s-Rl.2-2.3 (Rl.1-1.4,11.2-3, VT-Rl.2-2.3)) 

(Rl.2-2.4 ^ s-Rl.2-2.4 (Rl.1-1.5,11.2-3, VT-Rl.2-2.4)) 

(Rl.2-2.5 <- s-Rl.2-2.5 (Rl.1-1.6,11.2-3, VT-Rl.2-2.5)) 

(Rl.2-2.6^ s-Rl.2-2.6 (Rl.1-1.2,11.2-3, VT-Rl.2-2.6)) 

(Rl.2-2.7 s-Rl.2-2.7 (Rl.1-1.6, VT-Rl.2-2.7)) 

(Rl.2-2.8 <r- s-Rl.2-2.8 (Rl.1-1.2, VT-Rl.2-2.8)) 

Figure 63 C4I Systems Requirements Analysis Step (after [HARN99c]) 

Thus, there are a number of shorteomings with this funetionality. First, eaeh file 
assoeiation had to be individually ereated and managed, a laborious proeess. Seeond, 
beeause aetual artifaet data was not used in CASES (only referenees to the data), it was 
diffieult for the engineer to quiekly glean meaningful information from the referenees. 
CASESv2.0 addresses these shorteomings by providing an “imporf’ funetion in whieh 
the user is able to import atomie eomponent data directly into the tool. This situation is 
improved in CASESv2.0 where the engineer gains an intuitive feel for the relationships 
between atomic components through use of the project schema and individual QED 
matrices. 

In CASESv2.0, the software engineer registers the high level abstract 
component types in the project schema with specific atomic component data contained in 
.CSV (comma separated value) files produced from individual tools. CSV files are static 
fiat files easily created from ASCII text, spreadsheets, or database files. The engineer 
“imports” this atomic component data directly into CASES by “right-clicking” on a 
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component, identifying the partieular variant and version number and then navigating to 
the .esv fde (see Figure 64). 



Figure 64 CASESv2 Data Integration via Import CSV File (Requirements variant 2 

version 3) 

In Figure 64 the engineer imports the .esv file for the Requirements of variant 2 version 
3. This data ean then be seen and used in establishing QFD relationships within the 
CASESv2.0 QFD Matriees. 

3, QFD Matrices 

The third major extension needed to embed QFD into CASES is to provide a QED 
matrix eapability so that the engineer ean establish eorrelations between eomponents, 
enter or modify dependeney values, and then perform upstream and downstream 
deployment ealeulations. The engineer views and modifies a partieular QED matrix by 
“right-elieking” on a partieular step (edge) and seleeting “QED” followed by the 
partieular dependeney of interest. The user is then presented with a QED matrix with the 
input component on the left and the output component aeross the top (see Eigure 65). 
The engineer is then free to enter correlation values (typically 0, 1, 3, or 9 (see Chapter 
IV)) and to enter or modify dependeney values. Dependeney values may only be edited 
at the “origin” component (specified during dependeney creation). 
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Figure 65 QFD Matrix: Requirements x Specifications (Dependency: Reqt Risk) 

Finally, after all the correlation dependency values are entered, the user presses the 
“Calc” button the on the QFD dialog or the “Sync” button on the CASES toolbar and the 
tool automatically “deploys” the dependency. In the case of the “Calc” button, the 
dependency is only deployed to the components of the open QFD matrix. In the case of 
the “Sync” button, the dependency is deployed to all connected components in the 
software development effort. 

In Figure 65 the engineer was presented with a QFD matrix between 
“Requirements” and “Specifications” for the QFD dependency “Requirement Risk”. 
Note that the imported textual information (the requirement/specification numbers and 
names) was automatically displayed and allows the engineer to intuitively understand 
what linkages and comparisons are being established. The engineer could have imported 
the values for “Requirement Risk” via the .csv file or entered/edited those values 
individually. After entering in values of correlation between the requirements and the 
specifications, the engineer used the “Calc” button to deploy the Requirement Risk to the 
specifications. 

D. ENGINEERING VIEWS OF QFD DEPENDENCIES (SLICES OF THE RH 

MODEL) 

Simply creating QFD matrices and entering information into them does little to 
assist software engineers in building better software or in improving their software 
processes. In order to offset the overhead associated with gathering and entering this 
information, there must be means by which the engineers can quickly isolate and view 
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interesting information that will help them improve their software produet or improve 
their software development proeess. CASESv2.0 implements two sueh means by 
allowing the user to define two different views of QFD information; the Dependeney 
Threshold View and the Component Traee View. 

1. Dependency Threshold View 

The Dependeney Threshold View allows the engineer to isolate a subset of 
important (or unimportant) eomponents from the entirety of the development effort. This 
view is useful if the engineer wants to identify whieh eomponents have the greatest risk, 
or are the least diffieult, or are the most unstable. In eaeh of these eases, the engineer 
would have defined that partieular dependeney (risk, diffieulty, stability), assigned values 
to the dependeney and deployed the dependeney throughout the development effort. The 
Dependeney Threshold View then provides a means of isolating important information 
from the remaining noisy data in the development effort. 

To use the Dependeney Threshold View the engineer eompletes all eorrelation 
matriees and uses the synehronization funetion on the CASES tool bar to deploy all 
dependeneies throughout the entire development effort. Next, the engineer opens a 
partieular QED matrix of interest. Erom the “View” menu item of the QED dialog, the 
user seleets “Dependeney Threshold” and is presented with a dialog in whieh he ean 
seleet a threshold of interest based on the mean and standard deviations of the 
eomponents displayed. The mean value +/- the standard deviation of the dependeney 
values are used as opposed to speeifying a partieular threshold value beeause of the 
dependeney “thinning” and “eoneentration” effeets diseussed in Chapter IV. 

To illustrate the Dependeney Threshold View in CASESv2.0, reeall the example 
presented in Chapter IV where three requirements were deployed to four speeifieations 
(see Figure 66). 
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Figure 66 User-Defined Example from Chapter IV 

The CASESv2.0 QFD correlation matrix for this example is presented in Figure 67. This 
matrix corresponds exactly with the data presented in Chapter IV, Table 12. 



Figure 67 QFD Matrix: R x S (Dependency: Risk) 


From this QFD matrix, the engineer selects the “View” menu item and the 
“Dependency Threshold” option. As in the example presented in Chapter IV, if the user 
desires to view all components greater than the mean, he enters that into the dialog and 
the tool automatically trims the QFD matrix to show only those components meeting that 
criteria. The user can specify additional thresholds and the tool will continue to provide 
the appropriately trimmed matrices. Figure 68 illustrates two such matrices consistent 
with the example in Chapter IV in which the user desired to view all components with 
dependency values greater than the mean (upper left matrix) and a separate matrix of all 
components with dependency values greater than one standard deviation above the mean 
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(lower right matrix). Note that the resulting components match exactly those derived 
analytically as in the example in Chapter IV. 
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Figure 68 User-Defined Views with Threshold = ju and Threshold =ju + \a 


It is worth noting that these trimmed matrices equate to induced subgraphs of the 
underlying hypergraph representation of the entire development effort. These subgraphs 
have been induced by applying user defined threshold criteria against the deployed QFD 
dependency values. 

It is clear that by using such views the engineer could quickly identify specific 
subsets of development components that are of interest. For example, the engineer could 
quickly identify all the components that have the greatest risk, or identify the components 
that are most related to safety requirements provided by the users. Conversely, the 
engineer could quickly identify which components have little risk or no safety 
implications. Such specialized informational views provide important decision support 
information allowing software engineers to make better decisions as to where to allocate 
limited development resources. The Dependency Threshold View could be of benefit in 
numerous development situations and is only constrained by the type of dependencies 
created by the engineer and the engineer’s ability to accurately determine dependency 
values and component correlations. 

2, Component Trace View 

The Component Trace View is useful to the engineer so that he can identify all 
connected components of a particular component of interest. For example, if the 
engineer were having difficulty in implementing a particular architectural component, he 
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could use the Component Trace View to identify all connected components that 
influeneed (or are influeneed by) that particular component. Furthermore, because the 
correlations between components in QFD matrices all have particular values, the engineer 
can specify the degree of relationship he is interested in isolating. 

To use the Component Trace View the engineer completes all correlation matrices 
and uses the synchronization function of CASES tool bar to deploy all dependencies 
throughout the entire development effort. Next, the engineer opens the QFD matrix just 
upstream of the component of interest (i.e. so that the component of interest is listed 
across the top of the QFD matrix). From the “View” menu item of the QFD dialog, the 
user selects “Component Trace” and is presented with a dialog in which he can select the 
partieular component of interest and the threshold of correlation. For example if he 
seleets a threshold of 2, CASES will display all conneeted eomponents that have 
correlation values of 2 or greater. 

To illustrate the Component Trace View in CASESv2.0, recall the example 
presented in Chapter IV with requirements, specifications, architectural components, and 
software modules connected by three steps (see Eigure 69). 

Define 

Architectural Define 



The CASESv2.0 QED eorrelation matrices for this example are presented in 
Eigure 70. These matrices eorrespond exactly with the data presented in the component 
trace example from Chapter IV and in data in Eigure 69. 
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Figure 70 QFD Matrices for Component Trace Example 


Now suppose the user wants to perform a component trace from component A3 
(one of the architectural components). The engineer would select the middle matrix from 
those in Figure 70 (the matrix in which component “A3” is listed across the top). From 
this QFD matrix the user would select the “View” menu item and the “Component Trace” 
option. In the resulting dialog, the user would specify which component they desire to 
trace from and at what threshold value. CASESv2.0 then presents the user with a series 
of “trimmed” QFD matrices corresponding to each major step in the development effort 
in which the resulting trace exists. Figure 71 and Figure 72 illustrate the resulting 
trimmed QFD matrices related to component traces from component A3 with threshold 
values of 2 and 8 respectively. 



< r 2,01 
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Figure 71 QFD Trace from A3 (Upstream & Downstream) Threshold 2 


190 







































































































Ift Quality Function Deployment (QFD) House of Quality for Upstream Combined Trace Vtawr- 

1 File View | 




S3 


5.54 



R3 4 

9 i 




S3 


5.54 


43 

3,87 


Figure 72 QFD Trace from A3 (Upstream) Threshold 8 


As in the case of the Dependency Threshold Views, it is important to note that 
these trimmed matrices equate to induced sub-graphs of the underlying hypergraph 
representation of the entire development effort. These figures equate exactly to the sub¬ 
graphs derived analytically in the example in Chapter IV (recall Figure 45 and Figure 
46). These sub-graphs have been induced by applying user defined threshold criteria 
against the QFD correlation values based on linkages established in the project schema. 

Once again it is clear that by using such views the engineer could quickly identify 
specific subsets of development components that are of interest. For example, if the 
engineer where having difficulty implementing an important software module, the 
engineer could quickly view a trace of all previous components (architectural modules, 
software specifications, customer requirements) that led to the need for that software 
component. The engineer could then reason about ways in which the architecture could 
be modified or the requirement renegotiated in order to find a workable and agreeable 
solution to the implementation problem. Alternatively, suppose a change was being 
proposed to a safety critical requirement, the engineer could use the Component Trace 
View to identify the potential knock-on effect of the proposed change to quickly seeing 
all the effected components which would be impacted by the change in the single 
requirement component. As was the case with the Dependency Threshold View, the 
Component Trace View is a specialized informational view that provides important 
decision support information allowing software engineers to make better decisions as to 
where to allocate limited development resources. 
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E. CHAPTER SUMMARY 

This chapter presented the results of the research effort devoted to providing tool 
support for the HFSE. It provides an overview of the extensions made to CASES version 
1.1 to ereate CASES version 2.0 by [CEOM03]. The major eontributions provided by 
this improved version of CASES allow a software engineer to; design a custom software 
evolution model through the use of the CASES GUI; input, modify, and analyze 
dependency characteristics between software artifacts within a QED framework; and 
make deeisions based upon views of dependeney information. 

Together, these extensions provide the neeessary tool support that allow the 
establishment of the HESE and allow the HESE to be applied in actual software 
development scenarios. 
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VIII. VALIDATION 


A. APPROACH TO VALIDATION 

Recall that the dissertation hypothesis (presented in Chapter I) called for 
determining the theoretical feasibility of using the HFSE to improve the interoperability 
of software development tools and models. The overall approach to providing evidence 
confirming this hypothesis was to apply the HFSE to two software development tools and 
then use those tools in two software development scenarios. However, before discussing 
the experiment, the results, and implications of the results, the research hypothesis itself 
begs the following questions that must be addressed: 

• What is meant by “theoretical feasibility”? 

• What is meant by “interoperability”? 

• What is meant by “improvement” (of interoperability)? 

This section of the chapter will define these ambiguous terms, will present the 
experimental approach, and will discuss the employed risk mitigation and experimental 
scoping measures. 

1. Definitions 

a. Theoretical Feasibility 

Generally, there are three categories of feasibility to consider when 
conducting scientific investigation: theoretical, technical, and organizational. In 
theoretical feasibility the underlying concern is demonstrating that something could be 
accomplished (the experimental variable operating on the observation group producing an 
effect on the observation group) if adequate resources existed and were then applied to 
the effort. Theoretical feasibility can demonstrated through mathematical proof or by 
constructing a proof of concept technical prototype or simulation. In technical 
feasibility, the underlying concern is demonstrating that aU needed resources exist and 
are available for completely accomplishing the investigative task. Technical feasibility is 
demonstrated by completely implementing the process under investigation using 
established technology and then demonstrating that it works in real world situations. In 
organizational feasibility, the underlying concern is demonstrating that while something 
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might be possible and the teehnology exists to support it, that there are organizational 
reasons why it should be done. 

In the ease of this dissertation, only evidenee of theoretieal feasibility is 
established. There are two main reasons for this. First, the effort needed to demonstrate 
teehnieal feasibility of the HFSE by aetually integrating all existing software 
development tools via a single ideal dynamie middleware solution is a massive 
undertaking requiring many hundreds (if not thousands) of man-years of effort. Seeond, 
the ideal middleware meehanism used to implement the HFSE is not yet identified (and is 
eonsidered as an area for future researeh). In this dissertation, the manual exehange of 
statie fiat data files is used to demonstrate the theoretieal feasibility of the framework and 
provides evidenee that one sueh teehnieal solution is possible, but by no means should 
this simplistie middleware solution be viewed as the ideal teehnieal implementation. In a 
teehnieal feasibility study, several dynamie middleware solutions should be eompared in 
order to determine the most effieient one for implementation within the HESE for use in 
all real world settings. Einally, organizational feasibility is not eonsidered at all in this 
dissertation. While an organization’s rationale for potentially employing the HESE is 
aneedotally diseussed, no experimental evidenee is provided that would demonstrate 
eonelusively that real organizations have a desire (or an unaeeounted for eeonomie 
impetus) to implement the framework. 

b. Interoperability 

There are many definitions of interoperability. Eor instanee, NATO 
definitions of interoperability foeus on data exehange and define eategories (levels) of 
interoperability based on the type of data exehange possible between two systems 
[STANOO]. Eevel 1 interoperability eonsists of separate operators at two different types 
of systems manually entering in similar data into their systems; level 2 interoperability 
eonsists of the exehange of media (floppy dise, CDROM, ete.) whieh ean be read by two 
different systems; level 3 is the eleetronie exehange of eharaeter based message sets 
whieh ean be interpreted by different types of systems; ete. In all eases, the NATO 
definition of interoperability foeuses on the means, ease, speed, and eapaeity of data 
exchange. 
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[GANGOO] provides an alternative view of interoperability based on four 
perspeetives: physieal interoperability, data-type interoperability, speeifieation-level 
interoperability, and semantie interoperability. Physieal interoperability relies on the 
physieal exehange of eompatible eleetronie storage media. Data-type Interoperability 
foeuses on eontent and strueture of the information exehanged. In speoifieation-level 
interoperability, applieations that share data do not know the finer details of the data 
strueture, but rather treat information to be shared as a whole; COM and CORBA are 
examples. In semantie interoperability, a system is designed to use different abstraet 
views of shared entities. 

The definition of interoperability that will be used in this dissertation is the 
same one that [YOlJN02b] relied on for his OOMI methodology and is attributed to 
[PIT097]; 

Pitoura defines interoperability as the eapability of systems to exehange 
information and to jointly exeeute tasks. Full interoperability allows 
systems to take advantage of funetionalities and serviees that would 
otherwise not be available or would have to be implemented. 

In this definition, the eoneept that interoperability is more than just data exehange is key. 
The ability of users of the systems to aeeomplish joint tasks beyond the individual 
eapabilities of eaeh system is as an important aspeet of interoperability as is information 
exehange. It will be this “joint task exeeution” portion of interoperability (using artifaet 
information from different systems to identify dependeney relationships) that will be 
highlighted during the dissertation experiment. 

c. Interoperability Improvement 

In this dissertation “improvement” in interoperability will be eonsidered as 
any inerease in quantity, type, or speed of information exehange as well as any inerease 
in quantity, type, or speed of joint task exeeution. For instanee, if after the applieation of 
the HFSE to a set of software development tools, the tools ean exeeute new joint tasks 
(tasks they were not able to undertake prior to the applieation of the HFSE) this will be 
eonsidered an “improvement” to interoperability between the tools. Conversely, if two 
tools integrated via the HESE ean no longer exehange information or exeeute some 
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particular joint task that was possible before applieation of the HFSE, this will be 
eonsidered to be a “deeline” or “reduetion” in interoperability. 

2. Experimental Design 

a. Overview 

The experimental design of this dissertation involves applying the HFSE 
to a small subset of tools and then using that subset of tools in two software seenarios. A 
statie group eomparison will be undertaken to identify if “improvements” to 
“interoperability” exist in the integrated tool set when eompared to the interoperability 
available between the tools in the same development seenario without benefit of 
integration by the HFSE. In essenee, the experiment relies on a small representative 
subset of tools/models to show that the HFSE ean be used to unify them and to provide 
evidenee that the interoperability of the subset of tools is improved. In the diseussion of 
internal and external experimental validity, theoretieal arguments are then provided to 
eharaeterize the elass of tools and models that eould also be unified with additional effort. 

b. Static Group Comparison 

This dissertation relies on a statie group eomparison test to provide 
eonfirming evidenee of the dissertation hypothesis. Campbell and Stanley [CAMP63] 
point out that this eomparison is best eharaeterized as a "pre"-experiment beeause it falls 
short of the unbiased applieation of the seientifie method (the sourees of invalidity of the 
experiment are delineated later in this ehapter). This experiment ean be eharaeterized as 
an applieation of the experimental variable (X) upon an observation group (O) as shown 
below in Experiment 1 (the experimental notation is adopted from [CAMP63] in whieh 
the horizontal line represents the experimental eomparison of observation groups). 

X O Experiment 1 

O 

In this experiment 

O c {all software development tools and models}, and 
X = Applieation of the HFSE to O. 

A statie group comparison experiment "is a design in which a group which 
has experienced X is eompared with one that has not, for the purpose of establishing the 
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effect of X" [CAMP63]. In this specific dissertation experiment, the HFSE is applied to a 
selected subset of tools/models (Rational’s Requisite®Pro and SEATools). The 
performance of integrated subset of tools/models (after the application of the HESE) is 
then compared to the performance of same tools/models in a "stand alone" mode (i.e. 
without the benefit of integration by the HESE). The two groups are separately applied to 
the same software development scenarios. The comparison in this case will be to 
determine if there are any improvements in interoperability between the tools (i.e. 
improvements to data exchange and/or joint task execution). Specifically, the experiment 
will seek to accumulate evidence of additional data exchange and additional joint task 
execution enabled by the application of the HESE to the subset of tools/models. The 
experiment will also record counter-evidence that the HESE reduces (or inhibits) data 
exchange and/or joint task execution. 

The two software development scenarios consist of a small “toy” example 
involving several development iterations and a more complex real world software 
development effort focused on just a single portion of a development effort. The toy 
example consists of developing the classic “Hello World” application. While in the toy 
example the number of requirements, specifications, code modules, etc. are each 
relatively few (1 to 5 atomic components each), the scenario is illustrative of how the 
HESE helps to holistically integrate many different types of artifacts with several variants 
and versions each. The real world scenario consists of the development of five parallel 
software variants of the CARA infusion pump from the same set of software 
requirements. This scenario consists of just a few different types of components 
(requirements, questions & answers, and specifications) but with numerous atomic 
components in each (e.g. over 150 requirements). 

3, Sizing the Dissertation Investigation and Risk Management 
Because of the potential size of this dissertation research and the complexity of 
existing models and tools that needed to be analyzed, the following mitigation measures 
were employed; 

a. Limited Number of Software Development Tools Analyzed 

Only two software development tools were analyzed to any significant 

depth. The original dissertation plan of research called for the analysis of five 
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models/tools [PUET02a, b] in establishing the software development tool ontology. 
However, investigating two tool ontologies (see Chapter III) provided suffieient analysis 
for proving the theoretieal feasibility of the HFSE. The remaining effort was modified 
appropriately. 

b. Superficial Exploration for Counter-examples 

Onee the analysis of the models and tools was eomplete and a 
eharacterization for them was established, an exploration for eounter-examples was 
undertaken with the aim of improving the model. This consisted of the top-down 
approach used in developing the software development tool ontology (see Chapter III). 
This exploration was superficial in both breadth and depth, which is why the ontology 
was constructed to be extensible, so that additional future additions and modifications can 
be easily implemented in future research. 

c. Partial Implementation of Example Tools 

The primary goal of this research was only to formulate a framework that 
could be used to unify any/ah software development tools and models, not one that did 
unify them ah. This research did not seek to implement a complete federation of models 
and tools, nor did it seek to implement completely the tools considered (Requisite®Pro 
and SEATools). For instance, when incorporating Rational’s Requisite®Pro into the 
HFSE, only limited functionality was incorporated and used, not the entire functionality 
offered by the tool. 

d. No Validation against a real-world system 

The HFSE was not validated in a complete real-world software 
development effort. Both the “toy” scenario and the “CARA” scenario were 
accomplished as incomplete laboratory development efforts. While the software 
requirements for the “CARA” scenario are from a real-world software development 
scenario, the remainder of the CARA development artifacts (e.g. the software 
specifications) stem from a research environment. 

e. Early Implementation 

While still investigating parts of the HFSE, the extensions to CASESvl.l 
(leading to CASESv2.0) were ongoing. Setting up the HFSE sooner rather than later 

helped to bring to light new ideas and concepts that were incorporated into the effort. 
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Handling the most simplistic pieces of software in the HFSE allowed examination of the 
representation, communication, and temporal considerations of evolution of the 
development effort and identified needed additions and modifications to the extensions 
incorporated into CASES. 

B. CONDUCT OF THE EXPERIMENT 

In the conduct of the dissertation experiment, the HESE was applied to Rational’s 
Requisite®Pro and SEATools. The framework was then used in two software 
development scenarios: first, in a “toy” scenario consisting of a illustrative yet small 
development effort encompassing several complete development cycles with multiple 
versions and variants, and secondly, in a complex real-world example involving only the 
interaction between requirements and a single variant of software specifications. Each 
example provides confirming evidence of the dissertation hypothesis. 

1. “Hello World” Toy Software Scenario 

The first software development scenario conducted in the dissertation experiment 
is the classic “toy” example of “Hello World” which helps to clarify how the HESE can 
be applied to software development efforts consisting of multiple variants and versions. 
In this scenario a customer and developer interact to produce multiple variants and 
versions of a software application that displays “Hello World” on a computer screen. 
Together, the customer and developer apply a software development process shown in 
Eigure 73. 
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Q&A 



Figure 73 Hello World Development Process 


The customer begins by stating his requirements in Requisite®Pro (see Table 29). 
The customer identifies the priorities of his requirements using both the requirements 
priority attribute inherent in the Requisite®Pro tool as well as creating a new 
requirements attribute called “AHP Priority” and then using the Analytic Hierarchy 
Process (AHP) [SAAT80] to provide values for that priority. The customer also creates a 
second user defined requirements attribute called “Risk.” He assigns to risk, values 
associated with the potential (probably of outcome and level of consequence) for 
economic loss, should that particular requirement not be implemented as planned (l=low 
risk, 5=high risk). 
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RTag 

Requirement text 

Name 

ReqPro 

Priority 

AHP 

Priority 

Risk 

R1 

When commanded, the 
software must display the 
text "Hello World" at the 
terminal. 

Write Hello 
World 

High 

0.75 

4 

R2 

The text will be pleasing to 
the user. 

Pretty Font 

Medium 

0.0 

2 

R2.1 

The font will be Arial. 

Font 

Fow 

0.05 

1 

R2.2 

The font size will be 12. 

Font Size 

Fow 

0.05 

1 

R2.3 

The color of the font will be 
Green. 

Font Color 
Green 

Medium 

0.15 

2 


Table 29 Customer Requirements Variant 1 Version 1 (Rl.l) 


At the same time, the eustomer spins off a second variant of these requirements in 
which the font color is “Red” (see Table 30). Using the numbering scheme proposed in 
[LEHC99] and [HARN99c], this set of requirements is referred to as Variant 2, Version 

2 . 


RTag 

Requirement text 

Name 

ReqPro 

Priority 

AHP 

Priority 

Risk 

R1 

When commanded, the 
software must display the 
text “Hello World” at the 
terminal. 

Write Hello 
World 

High 

0.75 

4 

R2 

The text will be pleasing to 
the user. 

Pretty Font 

Medium 

0.0 

2 

R2.1 

The font will be Arial. 

Font 

Fow 

0.05 

1 

R2.2 

The font size will be 12. 

Font Size 

Fow 

0.05 

1 

R2.3 

The color of the font will be 
Red. 

Font Color 
Red 

Medium 

0.15 

2 


Table 30 Customer Requirements Variant 2 Version 2 (R2.2) 


After reading through the requirements, the developer responds to the customer 
with a question related to potential implementation to which the customer responds (see 
Table 31). 


QTag 

Q&A 

Name 

Qi 

Q: Is the use of a visual basic form 
good enough? A: yes. 

Visual Basic Form 


Table 31 Developer-Customer Question & Answer Version 1 «& 2 (Ql.l, Q2,2) 
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The developer proceeds by developing a single SEATools model of the system 
(see Figure 74) that models both variants of the customer’s requirements. 


Text HelloMorld 



Figure 74 SEATools Hello World Prototype Variants 1 & 2, Versions 1 & 2 

The developer uses the PSDL file from the SEATools model to make a list of the 
key specifications of the design based on the operators and data streams of the model. He 
also captures the “Required By” data for requirements traceability purposes. To each of 
these specifications, he assigns a level of difficulty (1= low difficulty, 9=high difficulty) 
based on his perception as the difficulty of fully implementing the particular specification 
into code. Table 32 lists these specifications. 


STag 

Specification 

type 

Name 

Difficulty 

Required By 

01 

Operator 

Hello World 16 

0 

R1 

01.1 

Terminator 

User Terminal 19 18 

2 

R1,R2 

01.2 

Operator 

Hello World 22 21 

3 

R1 

El 

State Stream 

Create HelloWorld 

1 

R1 

E2 

Data Stream 

Text HelloWorld 

1 

R2, R2.1,R2.2 

E3 

State Stream 

Text Color 

1 

R2, R2.3 


Table 32 Software Specifications Variants 1 & 2 Versions 1 & 2 (Sl.l, S2,2) 

The developer then assigns programmers to tackle particular portions of the 
application. The code hierarchy is similar for both variants and is shown in Table 33 and 
Table 34. Figure 75 provides screen shots of the actual implementation of both variants. 


CTag 

Code Description 

Name 

Cl 

HCI 

Forml 

Cl.l 

Text settings (green) 

Textl 

C1.2 

Command button 

Command 1 


Table 33 Code Variant 1 Version 1 (Cl.l) 
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CTag 

Code Description 

Name 

Cl 

HCI 

Forml 

Cl.l 

Text settings (red) 

Textl 

C1.2 

Command button 

Command 1 


Table 34 Code Variant 2 Version 2 (C2,2) 



Figure 75 Hello World Implementation Variants 1 «& 2, Versions 1 «& 2 

The developer provides the applications to a customer representative who 
performs validation testing of the variants against the originally stated customer 
requirements. The customer representative provides feedback as shown in Table 35. 


FTag 

Feedback 

Name 

FI 

The user should have the option to choose 
between Red or Green. 

Color Choice 

F2 

The function of the command button is 
exactly what the user wants 

Button works well 

F3 

The text size and font meet the customer’s 
needs 

Text Size & Font Good 


Table 35 Customer Feedback Version 1 & 2 (Fl.l, F2,2) 


Based on feedback item “FI,” the customer restates his requirements and asks the 
developer to generate another version of the application (variant 2, version 3). The 
updated customer requirements (with new priority and risk values) are shown in Table 
36. 


RTag 

Requirement text 

Name 

ReqPro 

Priority 

AHP 

Priority 

Risk 

R1 

When commanded, the 
software must display the 
text "Hello World" at the 
terminal. 

Write Hello 
World 

High 

0.527 

4 
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R2 

The text will be pleasing to 
the user. 

Pretty Font 

Fow 

0.0 

2 

R2.1 

The font will be Arial. 

Font 

Fow 

0.094 

1 

R2.2 

The font size will be 12. 

Font Size 

Fow 

0.046 

1 

R3 

The user will have a choice 
of font color as either Green 
(default) or Red. 

Font Color 

Medium 

0.333 

4 


Table 36 Customer Requirements Variant 2 Version 3 (R2,3) 


The developer updates his Q&A list with “Q2” (see Table 37) and modifies his 
SEATools model to aeeount for the new funetionality (Figure 76). 


QTag 

O&A 

Name 

Qi 

Q; Is the use of a visual basic form, good enough? 

A; yes. 

Visual Basic Form 

Q2 

Q; Is the use of radio buttons for choice, good 
enough? A: yes. 

Radio buttons 


Table 37 Developer-Customer Question & Answer Version 3 (Q2,3) 


Text HelloWorld 



Figure 76 SEATools Hello World Prototype Variant 2, Version 3 

The updated SEATools model leads to an updated list of software Specifications 
(see Table 38) with updated “difficulty” ratings. 


STag 

Specification 

type 

Name 

Difficulty 

Required By 

01 

Operator 

Hello World 16 

0 

R1 

01.1 

Terminator 

User Terminal 19 18 

2 

R1,R2 

01.2 

Operator 

Hello World 22 21 

3 

R1 

El 

State Stream 

Create HelloWorld 

1 

R1 

E2 

Data Stream 

Text HelloWorld 

1 

R2, R2.1,R2.2 

E3 

State Stream 

Text Color 

1 

R3 

E4 

Data Stream 

Text Color Cmd 

3 

R3 


Table 38 Software Specifications Variant 2 Version 3 (S2.3) 
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The developer reassigns programmers to the coding effort. The new code 
hierarchy is shown in Table 39. 


CTag 

Code Description 

Name 

Cl 

HCI 

Forml 

Cl.l 

Text settings 

Textl 

C1.2 

Command button 

Command 1 

C1.3 

Radio button (default) 

Option 1 Green 

C1.4 

Radio button 

Option2 Red 


Table 39 Code Variant 2 Version 3 (C2.3) 


Figure 77 illustrates the implemented variant/version. Note that in the center 
figure, no text color has been selected, yet “green” text color was displayed (i.e. a green 
default value was implemented). 



Figure 77 Hello World Implementation Variant 2, Versions 3 

The customer, satisfied with this final variant/version provides the feedback in 
Table 40. 


FTag 

Feedback 

Name 

FI 

Everything works will, ship the 
product 

Meets all Rqts 


Table 40 Customer Feedback Version 3 (F2.3) 


The developer turns the application over to the customer. This ends the Hello 
World software development scenario. 

2, “CARA Infusion Pump” Software Scenario 

The second software development scenario conducted in the dissertation 
experiment comes from a real world software development problem associated with the 
Computer Assisted Resuscitation Algorithm (CARA) [WRAIO1 a]: 
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The Computer Assisted Resuseitation Algorithm (CARA) is a closed loop 
software system that drives a high output infusion pump (Ml00) used for 
fluid resuscitation of patients suffering from conditions that lead to 
hypotension. The system will use blood pressure as the control for a 
proportional closed-loop control algorithm. The CARA system will be 
ultimately fielded on up to 3 platforms: LSTAT (Life Support for Trauma 
and Transport), DataPak and WPSM, collectively known as HOSTS. The 
software will have to accommodate various blood pressure inputs (e.g. 
arterial line, noninvasive cuff, pulse wave, etc)... The CARA is intended 
to support primary intravenous fluid resuscitation therapy to rapidly 
restore intravascular volume and blood pressure in patients with clinical 
shock, hypotension, and hypoperfusion states as a result of hemorrhagic 
blood loss, occult hemorrhage, neurogenic shock and septic shock. 
Currently the uses for the CARA system will be for combat casualties. 

In this software development scenario, five teams of developers were each given 
identical sets of CARA software requirements [WRAIOlc] (also Appendix B) and a 
historical set of discussions between developers and customers (framed as 133 questions 
and answers) [WRAIOlb]. These discussions often related directly to particular 
requirements in the requirement set and helped to clarify ambiguities in the requirements 
for the developers. A sample of these questions and answers is shown in Table 41. 


Tag 

Question 

Title 

Response 

Reference 

Reqmt 

Action 

Q38 

2/3/99 - Is the pause 
auto-eontrol mode 
necessary? 

AC Pause 
necessary 

2/3/99 - No, it can be 
eliminated to simplify the 
system and reduce the 
operating hazards. 

33, 35, 36, 

37, 38, 40, 
48.4.2 

Remove 33, 
35, 36, 37, 

38, 40, 

48.4.2 

Q39 

2/3/99 - Should 5 cuff 
measures be taken to 
calibrate the PW, or 
will fewer suffice? 

Less than 5 
readings to 
Calibrate 

Cuff BP 

2/3/99 - The number of cuff 
measures required for 
calibration should be 
reduced to 3. 

24.1 

24.1 

Q40 

2/3/99 - Will PA or 

CVP be used for auto¬ 
control? 

PA or CVP 
for AC 

2/3/99 - No. 


N/A 

Q41 

2/3/99 - When an 
action button is pressed 
does it remain 
available, or is it 
disabled? 

Action 

Buttons 

2/3/99 - The action button 
should be disabled (possibly 
removed) once the button 
has been pressed. 


49 


Table 41 Excerpt of CARA Questions and Answers (after [WRAIOlb]) 


From these requirements and discussions, each of the five teams then 
independently constructed a SEATools model of the CARA software. The teams did not 
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see their partieular development effort through to the eompletion of full funetioning 
exeeutable software systems, only to the specifieations development stage (as embodied 
as a SEATools PSDL file). The software development proeess model for this scenario is 
illustrated in Figure 78. 



Figure 78 CARA Software Development Process 


Note that this is an abbreviated software development process that concluded at 
the specifications development phase. The customer begins by stating his requirements 
in Requisite®Pro (see Appendix B). The customer identifies the priorities of his 
requirements using a user defined requirements attribute called “AHP Priority” and then 
using the Analytic Hierarchy Process (AHP) [SAAT80] to provide values for that 
priority. The customer also creates a second user defined requirements attribute called 
“Risk.” He assigns to risk, values associated with the clarity of requirements as measured 
by how frequently developers ask questions about that particular requirement. 
Requirements with low risk are those in which the developer asks no questions and those 
with high risk are those in which the developer asks multiple questions (l=low risk, 
5=high risk). The third user-defined requirement’s attribute is “Safety” in which the user 
again uses a 1 to 5 scale to indicate the importance of that particular requirement to the 
safety criticality of the overall system design. 

While all five SEATools models developed by the independent teams are 
described in detail and compared in [LE1QI02] and [LEIQI03], only one such model was 
used in the dissertation experiment and is explained in detail in Appendix C. Using the 
associated PSDL file of the graphic SEATools software model, a list of software 
development specifications was generated for the variant. This variant was numbered as 
1.1 in accordance with the numbering scheme presented in [LEHC99] and [HARN99c]. 
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An excerpt from the model 1 specifications is shown below in Table 42 (this portion of 


the specification relates to the 10 Module described in Appendix C). 


STag 

Spec Type 

Specification Name 

Required by 

01.2.2 

Operator 

10 Module 


01.2.2.1 

Operator 

alarm controller! 


01.2.2.1.1 

Operator 

Alarm Display Generator 

R6.1,R6.2, R7.1.1, 
R7.1.2, R8.1.1, 

R8.1.2, R15.1,R15.2 

01.2.2.2 

Operator 

alarm controller2 


01.2.2.3 

Operator 

button monitor 


01.2.2.4 

Operator 

displaydriver 


01.2.2.4.1 

Operator 

Pump_Plugged_in_Display_Driver 

R2,R2.1,R2.2,R2.3, 
R2.4, R2.5,R12.1 

01.2.2.4.2 

Operator 

ESTAT power on Display driver 

R1 

01.2.2.4.3 

Operator 

BP Graph and Value Driver 

R14.1.3,R14.1.4 

01.2.2.4.4 

Operator 

CARA Status Display Driver 

R16, R16.1,R16.2 

01.2.2.4.5 

Operator 

Voume Infused and Flow Rate Dis 
play Driver 

R10.2,R11.1, 

Rll.1.1 

01.2.2.4.6 

Operator 

Immediate Feeeback Display Driver 



Table 42 Excerpt from CARA Model 1, Specifications 1.1 


While the specific step by step software development activities for each team 
varied somewhat by team, the general process followed by all teams consisted of 
analyzing the requirements, clarifying requirements by considering the developer- 
customer questions and answers and then in building a SEATools model that satisfied the 
set of requirements and was consistent with the questions and answers. 


C. RESULTS AND CONFIRMING EVIDENCE OF THE HYPOTHESIS 

Applying the HFSE to Rational’s Requisite®Pro and SEATools, each of the 
software development scenarios was completed twice: once using tools that had not been 
integrated into the HFSE and once using tools that had been integrated with the HFSE. 

1. “Hello World” Results 
a. Questions Posed 

While completing the Hello World scenarios, the following questions were 
asked at particular points in the development effort. This set of questions is not 
exhaustive and many similar questions could have been posed in order to highlight 
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additional benefits of the HFSE. The questions and the presenee or absenee of answers 
are illustrative of the improvements of interoperability (additional joint task exeeution) 
provided by the HFSE. 

(1) If a ehange is made to requirement 2.3 (variant 2 version 
2), what other artifacts in the remainder of the development effort will likely change? 

(2) Which portion of the code poses the highest risk from a 
customer’s standpoint? 

(3) Which requirements lead to the most difficult 

specification? 

(4) What are the most difficult portions of the code? 

(5) Which artifacts will need to change based on customer 
feedback El (variant 2 version 2)? 

(6) Which pieces of code are the most important to the 


customer? 


(7) Are all requirements adequately covered by specifications? 

b. Non-HFSE Results: Hello World 

During completion of the non-HFSE scenario, none of the above questions 
could be answered quickly or reliably because there was no automated decision support 
information. Both the developer and customer could hazard guesses at each of these; 
unfortunately, there was no direct supporting analytical information for their answers. 

c. HFSE Results: Hello World 

During completion of the HFSE scenario, each of the above questions was 
answered reliably because there was automated decision support information available to 
the customer and developer. Elsing CASESv2 as the HFSE support tool, a project 
schema (Figure 79 below) was established that mirrored the software development 
process of development effort (recall Figure 73). 
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Figure 79 Hello World Project Schema 

Table 29 through Table 40 were used as CSV input to the project schema. 
Note that the “PSDL Model” and the actual application “Implementation” are not 
included as separate artifacts in the project schema since their information is actually 
embodied in the “Specifications” and “Code” artifacts, respectively. Dependency 
relationships were established for “ReqPro Priority,” “AHP Priority,” “Risk,” and 
“Difficulty.” Throughout the development effort, QFD correlations were established as 
appropriate between all components. As QFD correlations were completed, dependency 
calculations were synchronized, thus “deploying” the dependencies throughout the 
development effort. This deployment provided ready decision support information for 
answering the questions. Discussion of this automated decision support information 
follows. 

(1) Question 1 was, “If a change is made to requirement 2.3 
(variant 2 version 2), what other artifacts in the remainder of the development effort will 
likely change?” The answer was obtained by performing a “Component Trace” with 
threshold “1” on Requirement “2.3, variant 2, version 2” (see Figure 80). 
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Figure 80 Component Trace: R2.2-2.3, t=l 


The answer ineluded the following eomponents: S2.2-E3, C2.2-1.1, F2.2-1, and F2.2-3. 
The implieation to the developer was that given this information, he eould make a more 
accurate assessment of costs associated with making the single change to that 
requirement. While this specific decision support information only provided the number 
and type of components that would likely change, the developer could view particular 
QFD matrices with the “Difficulty” dependency of these components to obtain accurate 
information about the relative difficulty each of changing each of these components. 

(2) Question 2 was, “Which portion of the code poses the 
highest risk from a customer’s standpoint?” The answers to this question were obtained 
in less than 3 seconds for each variant by simply viewing the QFD Matrix “Risk 
Dependency” between Specifications and Code (see Figure 81). 


! Quality Function Deployment (QFD) House of Quality for Risk vTl.l 


File View 


Save & Exit 


01 

Hello World 16 

0.225 

01.1 

User Termina... 

2.725 

01.2 

Hello World 2... 

2.385 

El 

Create Hello... 

1.25 

E2 

Text.HelloWorld 

1.705 

E3 

Text Color 

1.705 



Cl 

Cl.l 

Cl .2 

Formi 

Textl 

Commandl 

3.11 

4.7 

2.18 


H 



3 

0 

;o 

3 

0 

0 

3 

0 

:o 

B 

3 

9 

B 

g 

0 

3 

3 

10 


Figure 81 QFD Matrix: Sl.l x Cl.l, d = Risk 

For Variant 1 and 2, version 1 and 2, the answer was the Cl.l “Textl” implementation 
piece of code with a risk value of 4.7. For Variant 2 version 3, the answer was the Cl.3 
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and Cl.4 pieces of code (implementation of the two radio buttons) with a risk value of 
3.65 (this make sense give that this was the new piece of functionality that was being 
added to the existing design). The implication to the developer was he should probably 
assign one of his better programmers to these pieces of code since they represented the 
highest level of risk to the customer. Incidentally, the same pieces of code (for variant 2 
version 3) had the highest level of priority from the user and had the highest level of 
difficulty from the developer. Together, these pieces of information allowed the 
developer to make an informed choice as to what resources to apply to this particular 
section of the code. 


(3) Question 3 was, “Which requirements lead to the most 
difficult specification?” The answer was obtained by opening the Requirement x 
Specification QFD Matrix for the Difficulty Dependency, then performing a “Component 
Trace” with threshold “1” on specification “01.2” (which has the highest difficulty value 
of “3”) (see Figure 82). 


i Quality Function Deployment (QFD) House of Quality for Difficulty w.1.1 


File 


View] 


Dependency Threshold 


Component Trace 


01 ,01.1 

01.2 }E1 

E2 

E3 

Hello WorL.jUser Term... 

Hello Worl...'create Hel... 

Text Hello... 

Text Color 

0.0 !2.0 

3.0 ll.O 

1.0 

1.0 


R1 

Write Hello Wo...13.82 

R2 

Pretty Font 

1.45 

R2.1 

Font 

0.55 

R2.2 

Font size 

0.55 

R2.3 

Font Color Ore... 

1.64 



Figure 82 Component Trace: 81,1-01,2, t=\ 


The answer included the following component Rl.1-1 (for variant 1 and 2, version 1 and 
2). In the case of variant 2 version 3, there where two specifications each with a level of 
difficulty of 3, therefore two separate traces were required which led to two requirements: 
R2.3-1 and R2.3-3. The implication to the developer was that should he run into trouble 
in implementing this relatively more difficult specification, he would know exactly which 
requirements would be affected. Note that this particular question could have simply 
been answered by considering the 01.2 column of the correlation matrix and looking 
across to the left 
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(4) Question 4 was, “What are the most difficult portions of the 
code?” The answers to this question was obtained by simply opening the QFD Matrix 
“Difficulty Dependency” between Specifications and Code and obtaining a “Dependency 
Threshold” view with the threshold equal to the mean (see Figure 83). 


(Quality Function Deployment (QFD) House of Quality for Deperidency Threshoid Vie 


File View 


C1 

C1.1 

Forml 

Textl 

3.08 

3.08 

^1 


01.1 |User Termina... 

2.0 1 

01.2 iHello Worlcl 2... 

3.0 


Figure 83 Dependency Threshold: Sl.l x Cl.l, d = Difficulty, t= fj. 


For Variant 1 and 2, version 1 and 2, the answer were the Cl “Forml” and Cl.l “Textl” 
pieces of code with a difficulty value of 3.08 each. For Variant 2 version 3, the answer 
was the Cl.3 and Cl.4 pieces of code (the color radio buttons) with a difficulty value of 
3.24. The implication to the developer was he should probably assign one of his better 
programmers to these pieces of code and perhaps should subject these pieces of code to 
more rigorous testing than other portions of the code. Once again, these QFD 
dependency information has allowed the developer to make an informed choice as to 
what resources to apply to these particular sections of the code. 

(5) Question 5 was, “Which artifacts will need to change based 
on customer feedback FI (variant 2 version 2)?” The answer was obtained by performing 
a “Component Trace” with threshold “1” on Feedback “FI, variant 2, version 2”. The 
resulting answer presented the developer with a set of components that included almost 
the entire underlying hypergraph meaning that almost every component might require 
change. The developer then modified his query and changed the threshold to 3 (see 
Figure 84). 
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Figure 84 Component Trace: F2.2-1, t = 3 


The answer included the following components C2.2-1.1; S2.2-E1, E2, E3; R2.2-1, 2.1, 
2.2, and 2.3. The implication to the developer was that given this information, he could 
make a more accurate assessment of costs associated with modifying the development 
artifacts in addressing that particular piece of feedback. While this specific decision 
support information only provided the number and type of components that would likely 
change, the developer could view particular QED matrices with the “Difficulty” 
dependency of these components to obtain accurate information about the relative 
difficulty each of changing each of these components. 

(6) Question 6 was, “Which pieces of code are the most 
important to the customer?” The answers to this question was obtained by opening the 
QED Matrix “AHP Priority Dependency” between Specifications and Code and obtaining 
a “Dependency Threshold” view with the threshold equal to the mean plus 0.5 standard 
deviations (see Eigure 85). 
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Figure 85 Dependency Threshold: S2,3 x C2.3, d = AHP Priority, t= ju + 0.5cr 

For Variant 1 and 2, version 1 and 2, the answer was the Cl.l “Textl” pieee of eode with 
an AHP Priority value of 0.44. For Variant 2 version 3, the answer was the Cl.3 and 
Cl.4 pieees of eode (the radio button features) with an AHP Priority value of 0.26. The 
implieation to the developer was he should probably assign one of his better 
programmers to these pieces of code and perhaps should subject these pieces of code to 
more rigorous testing than other portions of the code. Once again, this QFD dependency 
information has allowed the developer to make an informed choice as to what resources 
to apply to these particular sections of the code. 

(7) Question 7 was, “Are all requirements adequately covered 
by specifications?” The answers to this question was obtained by opening the QFD 
Matrix “Priority Dependency” between Requirements and Specifications and looking at 
the QFD correlation matrix (see Figure 86) to see if there were sufficient correlations for 
each requirement. While CASESv2.0 does not directly support the coverage calculation 
(delineated in Chapter IV), the developer could make a quick estimate by reading across 
the rows of the QFD matrix and ensuring that each high Priority valued requirement had 
relatively more total correlation than low Priority valued requirements. 
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Figure 86 QFD Matrix: R2,3 x S2.3, d = Priority 


For Variant 1 and 2, version 1 and 2, the answer was yes, the requirements were 
adequately eovered by specifieations. For Variant 2 version 3, the answer was also yes, 
the requirements were adequately eovered by speeifications. The implication to the 
developer was he did not need to develop any additional specifications to ensure that the 
customer’s requirements were adequately addressed. 

2, “CARA Infusion Pump” Software Scenario 
a. Questions Posed 

After completing the CARA development scenario, the following 
questions were asked at the end of the development effort. This set of questions is not 
exhaustive and many similar questions could have been posed in order to highlight the 
benefits of the HFSE. The questions and the presence or absence of answers are 
illustrative of the improvements of interoperability (additional joint task execution) 
provided by the FIFSE. 

(1) Which elements of the SEATools models are the most 


safety critical? 

(2) Which elements of the SEATools models are the most 
important to the customer? 

(3) Which elements of the SEATools models are the most risky 
(based on Requirements Clarity) from a customer perspective? 

(4) If requirement R34 were modified, which portions of the 
SEATools model would have to be modified? 
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(5) In Model 1, which questions/answers and requirements are 
related to the “Resuscitation Log”? 

(6) In Model 1, which questions/answers and requirements are 
related to the “Triple Modular Redundancy” feature of the design? 

(7) In Model 1, which questions/answers and requirements are 
related to the “Processor Watchdog” feature of the design? 

b. Non-HFSE Results: CARA 

After completion of the non-HFSE scenario, none of the above questions 
could be answered quickly or reliably because there was no automated decision support 
information. Both the developer and customer could hazard guesses at each of these; 
unfortunately, there was no direct supporting analytical information for their answers. 

c. HFSE Results: CARA 

After completion of the non-HFSE scenario, the Requirements, 
Questions/Answers, and SEATools models were integrated via the HFSE and 
CASESv2.0. Each of the above questions was then answered quickly and reliably 
because there was automated decision support information available to the customer and 
developer. Using CASESv2 as the HFSE support tool, a project schema similar to that of 
Figure 78 was established. Only model 1 (variant 1.1) of the five development variants 
was defined within CASES. The Requirements CSV file (similar to appendix B), the 
Q&A CSV file (similar to Table 41), and a SEATools Specifications file for the variant 
(similar to Table 42) were imported into the project schema. Dependency relationships 
was established for “AHP Priority,” “Safety” and “Risk.” QFD correlations were 
established as appropriate between all components. As QFD correlations were 
completed, dependency calculations were synchronized, thus “deploying” the 
dependencies throughout the development effort. This deployment provided ready 
decision support information for answering the questions. Discussion of this automated 
decision support information follows. 

(1) Question 1 was, “Which elements of the SEATools models 
are the most safety critical?” The answer was obtained by opening the QFD Matrix 
“Safety Dependency” between Requirements and Specifications and generating a 
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“Dependency Threshold” view with the threshold equal to the mean plus 1.5 standard 
deviations (see Figure 87). 
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Figure 87 Dependency Threshold: Rl.l x Sl.l, d = Safety, t= ju + l .5a 


The answer included the following SEATools specifications shown in Table 43. 


Variant/ 

Version 

Components 

1.1 

01.2.1.1.1.3 BP Priority Calculator, 

01.2.2.1.1 Alarm Display Generator, 01.2.2.3 button moniter, 

01.2.2.5.1 Display Alarm, E15 lost bp source, E28 display alarm data 


Table 43 Most Safety Critical Components: R x S, </ = Safety, t= ju + \.5a 


The developer could have increased or decreased the number of components in the 
answer by modifying the threshold. The implication of this information to the developer 
was that he could latter design more exhaustive testing of these particular components or 
perhaps he might choose to group the implementation of these specifications into distinct 
modules to which he would apply formal methods. This information allows the 
developer to make informed choices about how and where to apply limited development 
resources. 

(2) Question 2 was, “Which elements of the SEATools models 
are the most important to the customer?” The answer was obtained by opening the QFD 
Matrix “AHP Priority Dependency” between Requirements and Specifications and 
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generating a “Dependency Threshold” view with the threshold equal to the mean plus 2.5 
standard deviations (see Figure 88) 



Figure 88 Dependency Threshold: Rl.l x Sl.l, d = AHP Priority, t= ju + 2.5cr 
The answer included the following components shown in Table 44. 


Variant/ 

Version 

Components 

1.1 

01.2.1.1.1.3 BP Priority Calculator, 

01.2.2.1.1 Alarm Display Generator, 01.2.2.5.1 Display Alarm 


Table 44 Most Important Components: Rx S, </ = AHP Priority, t= // +2.Ocr 


Once again, the developer could have trimmed or expanded the number of components 
found by modifying the threshold of the search. The implication to the developer was he 
might want to assign one of his better programmers to these specifications and perhaps 
should subject the pieces of code generated from these specifications to additional 
validation testing to ensure that they meet or exceed customer’s expectations. Once 
again, this QFD dependency information has allowed the developer to make an informed 
choice as to what resources to apply to the development effort. 

(3) Question 3 was, “Which elements of the SEATools models 
are the most risky (based on Requirements Clarity) from a customer perspective?” The 
answer was obtained by opening the QFD Matrix “Risk Dependency” between 
Requirements and Specifications and generating a “Dependency Threshold” view with 
the threshold equal to the mean plus 1.0 standard deviations (see Figure 88) 
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Figure 89 Dependency Threshold: Rl.l x Sl.l, d = Risk, t= ju + \ Ocr 


The answer included the components shown in Table 45. 


Variant/ 

Version 

Components 

1.1 

01.2.1.1.1 BP calculator, 01.2.1.1.1.1 Aline Corroborator, 

01.2.1.1.1.3 BP Priority Calculator, 01.2.1.4.2 Terminate autocontrol, 
01.2.2.1.1 Alarm Display Generator, 01.2.2.3 button moniter, 

01.2.2.5.1 Display Alarm, 01.2.3.1 line monitor, 

01.2.3.1.2.2 Impedance Calculator, 01.2.3.1.3.2 Generate Air fault, 

E4 cuff bp, E14 real bp, E15 lost bp source, E28 display alarm data 


Table 45 Most Risky Components: RxS, </ = Risk, t=// + 1.Ocr 


Once again, the developer could have trimmed or expanded the number of components 
found by modifying the threshold of the search. The implication to the developer was 
that these specifications were directly traceable to requirements for which many 
questions were asked, an indication that the requirements were not as well understood or 
clear as other requirements. Again, the developer might want to undertake some form of 
mitigation (such as additional testing, or use his better programmers) in support of these 
particular specifications. 

(4) Question 4 was, “If requirement R34 were modified, which 
portions of the SEATools model would have to be modified?” The answer was obtained 
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by performing a “Component Trace” with threshold “3” on Requirement “34” (see Figure 
90). 
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Figure 90 Component Trace: Rl,l-34, t = 3 


The answer included the following components shown in Table 46. 


Variant/ 

Version 

Components 

1.1 

Q47 Terminate AC button, 01.2.1.4 Voting Element, 01.2.1.4.1 Vote, 
01.2.1.4.2 Terminate autocontrol, 01.2.2.3 button moniter, 

01.2.2.4 display driver, E13 operator commands 


Table 46 Component Trace: Rl,l-34, t=l 


The developer could have gained visibility over more or fewer components by varying 
the degree of the threshold of correlation (“3” was used here). The implication to the 
developer was that given this information, he could make a more accurate assessment of 
costs associated with making the single change to that requirement. 

(5) Question 5 was, “In Model 1, which questions/answers and 
requirements are related to the ‘Resuscitation Log’?” The answer was obtained by 
performing a “Component Trace” with threshold “1” on Specifications that were related 
to the resuscitation log. In the case of model 1, this included three specifications; 
“01.2.3.5 resuscitation_file operator”, “01.2.3.5.9 Resuscitation_file_Generator 
operator,” and “E38 resuscitation file data stream.” The Trace of the first specification 
in shown in Figure 91. 
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Figure 91 Component Trace: 81,1-01,2,3,5, t=\ 

The answer included the following components shown in Table 47. 


Trace 

Components 

01.2.3.5 

Features (FEAT) 5, 10.1, 11.2, 11.2.1, 12, 14, 14.1, 14.1.1, 14.1.2, 15.3, 
16.5.4, 17.1, 17.3.3.2, 17.4, 17.5, 17.6.2, 20.3.2, 20.6, 29.2, 44.4, 46, 
46.2, 47, 48.3.1.2, 52.1, 55, 56, 62, 66, 69 

01.2.3.5.9 

Features (FEAT) 5, 10.1, 11.2, 11.2.1, 12, 15.3, 16.5.4, 17.3.3.2, 17.4, 
17.5, 17.6.2, 20.3.2, 20.6, 29.2, 44.4, 46, 46.1, 46.2, 47, 48.3.1.2, 55, 56, 
62, 66, 69 

E38 

Features (FEAT) 5, 10.2, 11.2, 11.2.1, 12, 14, 14.1, 14.1.1, 14.1.2, 15.3, 
16.5.4, 17.3.3.2, 17.4, 17.5, 17.6.2, 20.3.2, 20.6, 29.2, 44.4, 46, 46.1, 
46.2, 47, 48.3.1.2, 52.1, 55, 56, 62, 66, 69 


Table 47 Component Trace: 81,1-01,2,3,5, 01,2,3,5,9, E38, t=\ 


The implication to the developer was that he could use the information to ensure his 
specification met all requirements associated with the resuscitation log. Alternatively, if 
changes were needed for the resuscitation log specification, he would know which 
requirements might need to be reexamined to ensure that the modified resuscitation log 
specification remained consistent with already specified requirements. 
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(6) Question 6 was, “In Model 1, whieh questions/answers and 
requirements are related to the ‘Triple Modular Redundaney’ feature of the design?” The 
answer was obtained by performing a “Component Traee” with threshold “1” on the 
speeifieations related to Triple Modular Redundaney. In the ease of model 1, two 
eomponents implement this feature; “01.2.1.2 Module2 operator” and “01.2.1.3 
Modules operator.” The answer was that no requirements or Q&As were related to this 
speeifioation. The implieation to the developer was that he had generated speeifieations 
for whieh there were no stated requirements. In this partieular ease, the developer eould 
query the eustomer to determine if sueh funetionality was needed or desired, or he eould 
delete these speeifieations from the design, or he eould ehoose to implement the 
speeifieations despite not having a requirements indueed rationale for the speeifieations. 
In any ease, the developer now has visibility over important design (and safety) 
information that was not available to him during the non-HFSE seenario. 

(7) Question 7 was, “In Model 1, whieh questions/answers and 
requirements are related to the ‘Proeessor Watehdog’ feature of the design?” The answer 
was obtained by performing a “Component Traee” with threshold “1” on the 
speeifieations related to the proeessor watchdog. This included three specifications in 
Model 1: “01.2.3.3 processor watchdog operator,” “E20 ping data stream,” and “E21 
acknowledgement data stream.” Much like question (6), the answer was that no 
requirements or Q&As were related to this specification. Once again, the implication to 
the developer was that he had generated specifications for which there were no stated 
requirements and as in the case of questions (6) the developer could query the customer 
to determine if such functionality was needed or desired, or he could delete these 
specifications from the design, or he could choose to implement the specifications despite 
not having a requirements induced rationale for the specifications. 

3, Evidence Confirming the Dissertation Hypothesis 

As illustrated above, in both development scenarios confirming evidence of the 

dissertation hypothesis was established. The HESE provided improvements in joint task 

execution in both scenarios. These improvements are illustrated by the information 

jointly generated by the subordinate development tools in response to specific questions 

about the development effort. While only seven questions were asked in each 
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development effort, many more sueh questions eould have been asked in order to provide 
quantitatively more evidenee; however, qualitatively, this evidenee would have been 
similar to that generated by the above set of questions. 


D. INTERNAL AND EXTERNAL VALIDITY AND EXPERIMENTAL 

IMPLICATIONS 

1, Internal and External Validity 

Campbell and Stanley [CAMP63] lay out the eonditions for whieh seientifioally 
sound experimentation should oeeur. In order for an experiment to be seientifieally 
sound, the experiment must bound sourees of internal and external invalidity. Internal 
validity deals with the question of whether or not the applieation of the proeess (X) was, 
in faet, the sole direet eontributing eause of the measured result. External validity deals 
with the question of whether the result ean be generalized to external populations, sets, 
ete. outside the experiment. The statie group eomparison that gathered eonfirming 
evidenee in this dissertation eontrols some (but not all) of these sourees of invalidity. 

2. Sources of Internal Invalidity 
a. History 

This souree of internal invalidity arises beeause of speeifie events 
oeeurring between measurements of the outeome that are in addition to the experimental 
variable. This souree was not eompletely eontrolled during the experiment beeause onee 
the tool set (O) was integrated by the HFSE, its state did ehange during the time period of 
the seareh for evidenee of improvements in interoperability of (O). The state ehanged 
beeause the experiment required seeking interoperability improvements during an aetive 
evolutionary software development effort (albeit a very limited development effort). 
While unlikely to be the eause, these state ehanges eannot be ruled out as the effeet of 
additional improvements in interoperability. The only way to have eontrolled this souree 
of invalidity would have been to repeatedly apply the HFSE to (O) after doeumenting 
eaeh improvement in interoperability (i.e. start from serateh eaeh time). Given that the 
main interest was in establishing evidenee in a eomplex evolutionary system, sueh an 
approaeh was impraetieal. Instead, the approaeh adopted to mitigate this souree of 
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invalidity was to determine and doeument the direet eause of eaeh improvement to 
interoperability. 

The implieations of “History” as a souree of invalidity on the experiment 
appear to be negligible. At no time were any of the improvements to interoperability 
traeeable to state ehanges within the integrated toolset. However, as stated above, this 
souree of invalidity, while mitigated, eould not be entirely ruled out. 

b. Maturation 

This souree of internal invalidity arises beeause of proeesses within (O) 
that may ehange as a funetion of time, independent of any applieation of the HFSE (X). 
This souree of invalidity was eontrolled in the eonduet of this experiment but eannot be 
ruled out if others attempt to repeat the experiment using a dynamie middleware HFSE 
eommunieations meehanism rather than the statie middleware meehanism used in this 
dissertation (i.e. importing statie CSV files). Beeause software development proeess 
tools may have internal proeesses that are aetivated solely by time (e.g. automatie 
updating/reetifying of databases) a dynamie middleware solution might ereate ehanges 
within CASES that eould possibly provide interoperability improvements not related to 
the applieation of the HFSE. Sueh proeesses would ehange the state of (O), meaning that 
it would not be possible to establish that the direet eause of differenees in (O) were a 
result of the HFSE (X). Fortunately, this was not the ease in this experiment. 

Beeause of the use of a statie middleware meehanism between aetive 
software development tools and CASES, it was not possible for “Maturation” to enter the 
experiment as a potential souree of invalidity. Therefore, there is high eonfidenee that 
the improvements in interoperability uneovered during the software development 
seenarios were not eaused by maturation. 

c. Testing 

This souree of internal invalidity arises when the aet of taking an 
observation ehanges the state of the observed item and thus infiuenees future 
observations. This souree of invalidity was adequately eontrolled sinee observing the 
evidenee of improved interoperability within CASES did not generate any ehanges to the 
state of the relationships stored within CASES. In all eaeh of the seenarios “views” of 
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existing data were obtained to provide eonfirming evidence. The underlying data 
remained unchanged. 

The implication is that there is high confidence that the improvements in 
interoperability uncovered during the software development scenarios were not caused by 
a “Testing” source of invalidity. 

d. Instrumentation 

This source of internal invalidity arises because of changes in the 
observing instrument or changes in the observers create a bias between measurements. 
This source of invalidity could have arisen in this experiment since the experiment was 
seeking "improvements in interoperability" — perhaps influenced by subjective opinion. 
The key for controlling this source of invalidity was to carefully define what an 
"improvement" means, to define what "interoperability" means, and to uniformly apply 
these definitions to the comparison set. As explained at the beginning of this chapter, the 
definitions used were as follows: 

• Interoperability: data exchange and/or joint task execution 

between two or more separate tools/models. 

• Improvement: evidence of the existence of interoperability found 
in the integrated tool/model set (type, quantity, speed), not found 
in the disjoint tool/model set. 

These definitions proved sufficient to explain or account for phenomena witnessed during 
the experiment; however, because of the numerous variables involved, it is not 
guaranteed that these definitions will prove adequate should others attempt to repeat the 
results. 

The implication is that “Instrumentation” was appropriately mitigated 
during the experiment, but cannot be ruled out in future experiments as others attempt to 
repeat these results. 

e. Statistical Regression 

This source of internal invalidity arises when the observation sample 
group has been selected from the extremes of the potential observation population. Since 
the tools/models selected for integration are more appropriately termed a "convenience" 
sample, this source of invalidity was not applicable to this experiment and therefore was 
controlled. 
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The implication is that there is high confidence that the improvements in 
interoperability uncovered during the software development scenarios were not caused by 
a “Statistical Regression” source of invalidity. 

f. Selection Biases 

This source of internal invalidity arises because of biases in the selection 
of the observation group (O). As mentioned in above, the observation group of tools 
integrated by the HFSE is best termed a convenience sample, chosen primarily on the 
basis of the availability of the tool/model. Two of the tools/models (SEATools and 
CASES) were specifically developed here at the Naval Postgraduate School with a view 
that they could be eventually integrated. Because these tools/models were hand-picked 
(SEATools as a participant in the observation group and CASES as the support tool of 
the HESE), this selection forms a bias and this source of invalidity was definitely present 
in the experiment and therefore was not controlled. To mitigate this somewhat, an 
outside, mainstream, commercial software development product (Rationale's Requisite 
Pro) was chosen as the requirements engineering tool. Also as a mitigation measure, 
each of the examples of joint task execution was considered in light of this particular 
source of invalidity. No evidence was found (but that does not mean it does not exist) 
that would indicate that this source was in fact the generative cause of the improvement 
in interoperability. 

The implication is that the improvements in interoperability uncovered 
during the software development scenarios could have been caused by a “Selection Bias” 
source of invalidity and not by application of the HESE to the observation group. The 
best way to overcome this limitation would be to undertake as future research, additional 
experiments in which other tools (non-NPS developed research software development 
tools) are chosen for integration in the HESE. Just such an experiment is proposed in the 
“Euture Research” section of Chapter IX. 

g. Experimental Mortality 

This source of internal invalidity arises when there is a loss of part of the 
observation group during the experiment. Application of the HESE did not result in the 
loss of any portion of the tools in the observation group; therefore, this source of 

invalidity did not occur and therefore was controlled. 

227 



The implication is that there is high confidence that the improvements in 
interoperability uncovered during the software development scenarios were not caused by 
an “Experimental Mortality” source of invalidity. 

h. Selection-Maturation Interaction. 

This source of internal invalidity arises in multi-observation group 
experiments when interaction between the observation groups is mistaken for the effect 
of the experimental variable. Since this experiment did not involve the interaction of the 
two observation groups, it cannot occur and therefore was controlled. 

The implication is that there is high confidence that the improvements in 
interoperability uncovered during the software development scenarios were not caused by 
a “Selection-Maturation Interaction” source of invalidity. 

3. Sources of External Invalidity 

a. Interaction of Testing and X 

This source of external invalidity arises when a pretest might change the 
observation groups' responsiveness to the experimental variable. In this case, no pretest 
was applied to the observation group, therefore there is no opportunity for bias. Thus, 
this source of invalidity was controlled. 

The implication is that there is high confidence that a “Selection- 
Maturation Interaction” source of invalidity was not present in the experiment. Thus, 
from this particular perspective (Selection-Maturation Interaction), the improvements in 
interoperability uncovered during the software development scenarios could be repeated 
in experiments in which other randomly chosen software development tools are 
integrated via the HFSE. 

b. Interaction of Selection and X 

This source of external invalidity arises because of interaction effects 
between the selected observation group and the experimental variable. In this case, the 
experimental variable (X) is the application of the HFSE, which has as its core the 
Hypergraph Evolution Model integrated in the CASES support tool. This model and 
SEATools were originally designed to work together. Therefore, their interaction may 
have unfairly biased the generality of the result. Thus, this source of external validity 
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was not controlled and brings into question the praetieal applieation of the HFSE on 
other, randomly seleeted tools/models. 

The implication is that there is low eonfidence that there was an absenee 
of a “Seleetion-Maturation Interaetion” souree of invalidity in the experiment. Thus, 
from this particular perspective (Interaction of Selection and X), the improvements in 
interoperability uncovered during the software development scenarios might not be able 
to be repeated in experiments in which other randomly chosen software development 
tools are integrated via the HFSE. The best way to determine this is to undertake sueh an 
experiment (see Chapter IX, Future Researeh). 

c. Reactive Arrangements 

This souree of external invalidity arises beeause of the reactive results of 
experimental arrangements. For instance, if all the tools chosen for the experiment all 
had a particular type of API it is not valid to conelude that the result of the experiment is 
generally applicable to all tools (for instance, those without APIs). Such a situation did 
exist in this experiment because there are many types of APIs (an essential aspeet of how 
the individual tool ontologies were integrated) but only two sueh interfaees were used 
(the COM API of Requisite®Pro and the static PSDF output file of SEATools). Thus, 
this source of invalidity was not eontrolled. It is worth noting, though, that during 
eonduet of the experiment there did not seem to be any extraordinary measures needed in 
order to integrate the two available APIs. 

Therefore, there is low confidence that there was an absence of a 
“Reactive Arrangement” source of invalidity in the experiment. Thus, from this 
particular perspective (Reactive Arrangements), the improvements in interoperability 
uncovered during the software development scenarios might not be able to be repeated in 
experiments in whieh other randomly chosen software development tools are integrated 
via the HFSE. The best way to determine this is to undertake many sueh experiments 
testing as many different types of APIs as possible (see Chapter IX, Future Researeh). 

d. Multiple-X Interference 

This source of external invalidity arises when there are multiple treatments 
of the experimental variable on the same observation group. Since the HFSE was only 
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applied once to integrate Requisite®Pro and SEATools, there was no opportunity that 
this source of invalidity occurred. Thus, it was controlled. 

The implication is that there is high confidence that a “Multiple-X 
Interference” source of invalidity was not present in the experiment. Thus, from this 
particular perspective (Multiple-X Interference), the improvements in interoperability 
uncovered during the software development scenarios could be repeated in experiments 
in which other randomly chosen software development tools are integrated via the HFSE. 

4. Summary of Experimental Validity 

Table 48 (below) summarizes the sources of invalidity associated with the 
proposed experiment. It is evident, that even with mitigation measures that there are a 
number of sources of invalidity. Because of the scope of this research, these sources of 
invalidity were not formally mitigated (only discussed). However, in Chapter IX Future 
Research, additional experiments that would directly address and account for these 
shortcomings are presented. 
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Sources of Internal Invalidity 

History 


Maturation 

Y 

Testing 

Y 

Instrumentation 


Regression 

Y 

Selection 

X 

Mortality 

Y 

Interaction of Selection 
& Maturation 

Y 

Sources of External 
Invalidity 

Interaction of Testing 
and X 

Y 

Interaction of Selection 
and X 

X 

Reactive Arrangements 

X 

Multiple-X interference 

Y 


Legend: 

Y the source was controlled 
X the source was not controlled 
~ the source was mitigated 


Table 48 Summary of Sources of Invalidity 

The summarized results of Table 48 succinctly illustrate the strengths and 
weaknesses of the experiment. In terms of internal validity, each source was either 
totally controlled or adequately mitigated with the exception of “Selection.” Thus, 
confidence is high (but not necessarily conclusive) that application of HFSE and not 
some other internal source was in fact the cause of the improvements in interoperability 
observed in the experiment. To conclusively demonstrate that the HFSE is the sole 
cause of the improvement to interoperability, additional experiments in which randomly 
chosen tools are integrated into the HFSE should be undertaken. Such an experiment is 
proposed as future research. 

The summarized results for external validity are not as strong as those for internal 
validity. The potential presence of “Interaction of Selection and X” and “Reactive 
Arrangements” sources of external invalidity cast doubt on the generality of the result. 
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The best way to prove this generality would be to eontinue to perform multiple similar 
experiments using randomly ehosen sets of tools. Sueh experiments are proposed as 
“Future Researeh”. 

E. CHAPTER SUMMARY 

This ehapter presented the validation approaeh used in the dissertation to obtain 
evidenee eonfirming the dissertation hypothesis. The experiments used to obtain the 
eonfirming evidenee were presented and explained. The eonfirming evidenee of 
improved software development tool interoperability was identified. The sourees of 
invalidity of the experiment were identified. In terms of internal validity, there is high 
eonfidenee that the HFSE does produee improvements in interoperability (thus high 
eonfidenee in the validity of the dissertation hypothesis). In terms external validity, more 
experimentation is needed in order to determine if there are any limitations on the elasses 
of tools that might be integrated into the HFSE with additional effort. 
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IX. CONCLUSIONS 


A. REVIEW OF THE DISSERTATION CONTRIBUTIONS 

1. Accomplishment of the Research Goal 

This dissertation provides eonfirming evidenee of the researeh hypothesis. In 
partieular, this dissertation demonstrates the following: 

a. Construction of the HFSE is Feasible 

As shown in Chapters III, IV, V, and VIII, it is theoretieally feasible to 
establish a Holistie Framework for Software Engineering that eonsists of a Software 
Evolution model extended with QED and integrated with a Eederation Interoperability 
Objeet Model of subordinate software development models and tools. 

b. HFSE Artifacts Can be Described Mathematically 

As explained in Chapter IV it is possible to mathematieally deseribe the 
HESE eonstruets using graph and matrix mathematieal notation and to then use linear 
algebra to deploy defined dependeney values to other artifaets throughout a software 
development effort. 

c. The HFSE Increases Software Tool Interoperability 

Confirming evidenee was presented in Chapter VIII that the applieation of 

the HESE to a sample set of software development tools (Requisite®Pro and SEATools) 
inereases the interoperability (data exehange and joint task exeeution) of the seleeted set. 

2. Other Original and Unique Contrihutions 

Beyond aehieving the dissertation researeh goal, this dissertation provides several 
other eontributions to the field of software engineering. 

a. Development of a Software Development Tool Ontology 
Construction Methodology 

Chapter III provides the blueprint for building a software development 
tool ontology. The methodology was adapted from other sourees (notably [USCH96]), 
but was tailored for identifying and eapturing the unique eharaeteristies of software 
development tools. This methodology ean be used to add additional software 
development tools to the already existing tool ontology presented in Chapter III. 
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b. Construct a Pilot Software Development Tool Ontology 

Chapter III presents the beginnings of a software development tool 
ontology. Three separate ontologies (and their inter-relationships) are presented: a high- 
level software development tools ontology, an ontology that deseribes the Common 
Objeet Model (COM) interfaee of Requisite®Pro, and an ontology that deseribes 
important (from an interoperability viewpoint) elasses from SEATools. 

c. Use the QFD Methodology to Deploy Software Dependencies 
other than Quality 

Chapters IV and VIII demonstrate a methodology for deploying definable 
software dependeneies throughout a software development effort. To date, the main 
software dependeney deployed using QFD has been a eustomer's view of quality as 
defined through the prioritization of eustomer requirements. While the theoretieal 
deployment of other dependeneies (sueh as eost, reliability, new teehnology, seeurity, 
ete.) have been proposed by other authors, there have no proposed methods for deploying 
these other dependeneies. This dissertation presents sueh a method. 

d. Apply OOMI to the Software Development Tool Domain 

Chapter V demonstrates how Young's Objeet-Oriented Model for 

Interoperability for heterogeneous systems was applied to an entirely different domain 
(other than C4I systems) by establishing a Federation Interoperability Objeet Model 
(FIOM) between software development proeess models and tools. This effort provided 
an appreeiation of the diffieulties in applying Young's methodology to a set of legaey 
heterogeneous software systems. 

e. Use the HFSE to Provide Perspective Views of the Development 
Effort 

Chapter VII explains the tool support that provides two user defined 
perspeetive views of partieular aspeets of a software development effort. The views 
presented inelude the Component Traee view and the Dependeney Threshold view. 
These views allow the user to glean important deeision support information from the 
underlying hypergraph of the software development effort. Sueh deeision support ean be 
later shown to provide software proeess and produet improvements. 
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2. Potential Long-Term Benefits to the Field of Software Engineering 

Establishing the feasibility of the HFSE and the other eontributions provided in 
this dissertation provide signihcant long-term benefit to the field of software engineering. 
While none of these potential benefits were proven in this dissertation, the dissertation 
forms the foundation upon whieh these benefits ean be proven in future researeh. These 
potential benefits ean be realized in three main areas. 

a. Improved Software Development Processes 

The HFSE provides a framework that provides software engineers a 
unique holistie view of their software development proeesses. This holistie view should 
lead to identifying unrealized effieieneies and improvements in the proeess of developing 
software. Applieation of the HFSE should provide eoherenee to the development effort, 
ensuring that the best effort of one part of the effort feeds the best effort of the next and 
that eaeh of these best efforts ean be direetly traeed baek to the features and aspeets of the 
design that were of the greatest importanee in the eyes of the eustomer. 

b. Improved Software Products 

Improvements to the software development proeess will inevitably lead to 
improvements in the produet itself Engineers will be able to more easily identify 
portions of the design upon whieh to foeus additional resourees and be able to identify 
portions of the design whieh would likely not be affeeted by a seareity of resourees. 
Together sueh efforts will lead to better software, produeed on time and on budget. 

c. Recognition of Unrealized Software Development Dependencies 

Finally, the HFSE provides researehers a framework upon whieh to 

explore software development dependeneies, potentially diseovering unrealized 
dependeneies in the proeess whieh in turn will eventually lead baek to improved 
development methods and produets. 

B, RESEARCH ISSUES ADDRESSED 

There were a number of issues originally identified in the dissertation proposal 
that were addressed while eompleting this researeh. Initially posed as questions, answers 
were diseovered while eompleting the dissertation researeh. 
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1 . 


Software QFD 

a. Questions 

In the application of QFD to Software, what makes software significantly 
different than other products? What are the implications of these differences in extending 
the Software Evolution model? 

b. Answer 

In Chapter II (particularly in the review of the work by Zultner [ZULT90, 
92, 93]), there were a number of differences identified that must be accounted for when 
applying QFD to software. Most of this work centered on the tailoring of the QFD 
matrix set. This is exactly what the HFSE does; it uniquely tailors a set of QFD matrices 
to the actual software development process that the engineers use. 

2, Automation of Requirement Prioritization 

a. Question 

Is it possible to "objectify" and/or "partially automate" prioritization of 
software requirements? 

b. Answer 

As discussed in Chapter IV there are a number of means of establishing 
dependency values (requirement prioritization being one such dependency). One of the 
most rigorous methodologies is Saaty’s Analytical Hierarchy Process (AHP) [SAAT80]. 
While automated tool support is available to support these calculations (for instance 
ExpertChoice® software is a tool that supports AHP), inevitably human interaction is 
required because it has not yet been possible to formally define the numerous factors that 
must be considered in establishing such judgments. Thus, partial automation to support 
dependency valuation is feasible, but totally automating the process is beyond current 
capability. 

3, Automation of Dependency 

a. Question 

In establishing the strength of dependency between Software artifacts, is it 
possible to "objectify" and/or "automate" the process? 
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b. Answer 

While not confirmed in this dissertation, the automation of similar tasks in 
support of the dissertation indicate that it is likely possible to partially automate the 
establishment of dependency relationships through implementation of dependency rules 
during data exchange. As an example, in Chapter VIII there were numerous cases in 
which the “Required by” data available from SEATools (a data field that contains a text 
reference to which requirement led to the establishment of particular timing constraints) 
was used in order to manually identify the cells in the QFD correlation matrix (the 
Requirement x Specification matrix) that required input. It should be fairly 
straightforward to construct a unique rule that would automatically insert a dependency 
value (e.g. “3”) for any such a relationship. How to generalize such a relationship to 
provide a range of values would be more problematic and would require more 
sophisticated rule sets that could use limited supplied tool information to resolve often 
subtle distinctions between dependencies. 

As an additional note, consideration of this research issue identified a 
shortcoming of the SEATools PSDE grammar, namely, the lack of a “Required By” field 
for establishing data streams and state streams. Currently, SEATools provides no 
traceability construct for the requirements leading to the creation of data streams. The 
PSDE grammar should be modified to add this capability. 

4, QFD Dependencies 

a. Question 

When identifying the dependencies between QED items, do QED 
dependencies currently accommodate all the needed relationships presented by 
"software" or is there a need to identify new relationships? 

b. Answer 

While certainly not exhaustive, the work done during this dissertation 
research does not yet indicate the need for additional constructs beyond “dependencies” 
with specific attributes such as name, description, range of values, type, default value, 
origin, current value. However, there were issues as to how to properly interpret tool 
values for particular dependency values so that they could be accurately deployed. As an 

example, Requisite®Pro automatically tracks a dependency called “Stability.” This 

237 



requirement attribute is a statement of how frequently a particular requirement has 
changed when compared to other requirements. It is recorded as High, Medium, or Low. 
The issue to the HFSE, was how to interpret this step function during deployment. For 
instance, interpreting the function as High;Medium:Low = 3:2:1 produces different 
results than interpreting it as 9:3:1. Thus, it would be useful to conduct additional 
research to investigate this issue and attempt to identify characteristics that should be 
considered when attempting to interpret the relationship of values within a particular 
dependency. 

5, QFD and the RH Model 

a. Questions 

To what objects, within the Software Evolution model, should QFD 
information be applied? In extending the Relational Hypergraph, is it better to encode 
QFD information in the step attributes or component attributes or would it be better to 
define new dependency objects? 

b. Answer 

A direct comparison study comparing the benefits of encoding QFD 
information in different objects within the Relational Hypergraph model was not 
undertaken in this dissertation. Instead, dependencies were established by superceding 
the primary input driven and secondary input driven dependencies of the RH model 
and replacing them with a range of dependency types and values. In particular, steps 
(activities denoting impetus to create components) were distinguished from dependencies 
(relationships between two components). This was done not because of any particular 
benefit provided by the RH model’s dependencies, but instead as an effort to minimize 
the number of additional changes to the existing RH model. 

6. Monitoring Artifacts 

a. Questions 

When integrating the Evolution System with the Object Federation, how 
will the Evolution system "monitor" activity in the object federation? How will it 
monitor activity in subordinate models and tools that does not trigger federation activity? 
Which activities should be monitored to achieve which purposes? 


238 



b. Answer 

The mechanism employed in this dissertation to “monitor” activity was 
very rudimentary and involved the importing of static data files created by subordinate 
software development tools. As future research, investigation into the use of the dynamic 
capabilities of middleware (e.g. CORBA, COABS, etc.) should be undertaken as a means 
of performing active monitoring via publish and subscribe mechanisms. 

7. HFSE Communications 

a. Question 

What medium will be used for communication between the Evolution 
Model and the Object Federation, between the Object Federation and subordinate 
tools/models (e.g. publish and subscribe, etc.)? 

b. Answer 

The full gamut of communications/data transport mechanisms was not 
explored in this dissertation. The original idea was to implement a dynamic middleware 
mechanism such as CORBA or COABS in order to dynamically keep track of changes to 
all software development artifacts. Unfortunately, this concept proved to be too 
ambitious and a less complex mechanism (importing static CSV files) was used to 
demonstrate the theoretical feasibility of the HFSE. This does not negate the need for 
future research that should be undertaken to prove the technical feasibility of the HFSE 
(as opposed to the theoretical feasibility established in this dissertation). In such a study, 
multiple mechanisms should be compared in order to determine the ideal 
communications mechanism for the HFSE. 

8. HFSE and APIs 

a. Questions 

To be realizable in practice, is the scope of tools to be integrated with the 
HFSE restricted to those that provide APIs? Another issue is how to integrate GUI’s - 
this probably cannot be done without changing them to some degree, and most real tools 
do not provide source code. Thus, will GUI’s have to be replaced via API’s? 

b. Answer 

In order to keep this research within a manageable scope, only two tools 
were examined in detail. One of these tools had a defined API (Rational’s RequisitePro) 
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while the other tool did not (SEATools). In both oases there were no partioular problems 
in adapting the standard output of the tools in suoh a way to provide meaningful input to 
CASES. However, this issue is far from settled. As future researoh, an investigation 
should be undertaken to determine the feasibility of integrating into the HESE a software 
development tool that only provides graphio output. 

9. Missing and Ambiguous Data 

a. Question 

How will missing and ambiguous data be aeeounted for in the HESE? 

b. Answer 

As explained in Chapter V, Young’s OOMI methodology is used to 
provide the bridge for missing or ambiguous data. The objeet relationships established in 
the OOMI provide a faeility for software engineers to provide speeifie translators 
between separate objeet eonstruets in two or more objeet models. Within eaeh of these 
translators, the engineer ean define speeifie eases to handle missing or ambiguous data. 

10. HFSE Extensibility 

a. Questions 

What attributes within the HESE must be modified to provide 
extensibility? What meehanisms will be used to provide extensibility? 

b. Answer 

Chapter III explains the use of an underlying software development tool 
ontology that is leveraged to form the EIOM upon whieh the HESE is based. This 
ontology was purposely eonstructed to be extensible so that other additional tools eould 
be added in the future. 

11. Process Dependencies and the HFSE 

a. Questions 

When analyzing the Rational Software proeess, do the phases of the 
Rational proeess have any effeet on the visible/needed tool eapabilities? What is their 
operational signifieanee, if any? Do they affeet the HFSE modeling eonsiderations at all? 

b. Answer 

In the end, this dissertation research did not focus on the Rational 
Software development process. Instead the HFSE was established to be independent of 
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process so that any software development proeess eould be aecommodated. Chapters IV, 
VII, and VIII provide many examples of how any software development proeess eould be 
aeeommodated within the framework. 

12. The HFSE and GUI Consoles 

a. Questions 

What elements of the HFSE lend themselves to establishing a GUI (for 
researeh purposes only) that provide the researeher relevant information about the 
underlying interaetion of the tools/models? What items of information would be of 
interest? 

b. Answer 

As diseussed in Chapter VII one of the main extensions to CASES was the 
addition of a graphieal interface for providing informational views of software 
development artifaets and dependeneies. One of the additions ineluded the development 
of a graphieal projeet sehema drawing pane in whieh the software development proeess is 
represented; this view shows the relationship between the major types of software 
development artifaets and the aetivities that generate them. Additionally, two user- 
defined views allow the software engineer to induee specifie subgraphs of the underlying 
hypergraph of the software development effort. Together, this graphieal interfaee 
provides a powerful tool for researehers to gain insight into the relationships between 
software development artifaets. 

However, it was noted during the testing and use of CASESv2.0 that this 
interface eould be improved. In partieular, an additional useful feature would be a tool 
that eould assist the engineer in establishing eorrelation values; allowing the engineer to 
eomplete pair-wise eomparison of eomponents. 

C. RECOMMENDATIONS FOR FUTURE RESEARCH 

The aehieved short-term goal of the dissertation researeh demonstrated that 
applying the HFSE to a seleeted tool/model set was theoretieally feasible. The long-term 
goals stemming from this researeh are to aetually improve the effieieney of software 
development proeesses and to improve developed software's quality, safety, and 
reliability. Given the extensive seope of these long-term goals, there are a number of 


241 



items that can be identified as future research that should be undertaken after the 
completion of this dissertation. 

1. Follow-on Hypotheses 

The logical follow-on research to this dissertation is to establish that application 
of the HFSE actually improves the efficiency of the software development process and 
improves the software itself Possible hypotheses include the following: 

• Employing a Holistic Eramework for Software Engineering 

(HESE) improves the efficiency and effectiveness of software 
development processes. 

• Employing a Holistic Eramework for Software Engineering 

(HESE) improves the quality, safety, and reliability of software. 

Each of these hypotheses is at least as large an undertaking as the research conducted in 

this dissertation. 

2. Comprehensive Model Validation 

As discussed in Chapter Vlll, the experiment undertaken to provide confirming 
evidence of the dissertation hypothesis had a number of shortcomings. An additional line 
of research related to the HESE would be to undertake a more comprehensive experiment 
to validate the HESE model. In order to adequately validate the HESE or to provide 
evidence of any of the future hypotheses above, the researcher should undertake a 
"Posttest-Only Control Group Design" experiment. This experiment would adequately 
control both internal and external sources of invalidity. 

Campbell and Stanley [CAMP63] point out that the "Posttest-Only Control Group 
Design" experiment is a scientifically sound method of determining the effects of an 
experimental variable on an observation population. This experiment can be 
characterized as shown in Experiment 2. 

R X O Experiment 2 

R O 

In this experiment 

R = Random selection, 

O c {all software development tools and models}, and 
X = Application of the HESE to O. 
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This is an experimental design in whieh a randomly seleeted group that has 
experieneed X is eompared with a randomly seleeted one that has not, for the purpose of 
establishing the effeet of X. In this speeifie experiment set in the eontext of validating 
the benefits of the HFSE, the groups to be eompared would be the same randomly 
seleeted set of tools, randomly seleeted from the population of all software development 
tools. One group is exposed to the HFSE and one is not. Both are used to undertake 
identieal software development efforts. Objeetive eriteria for eomparing performanee of 
the two observation groups would be established beforehand. The experiment should be 
run several times to provide for a suffieiently large sample size from the available set of 
tools/models. 

3. Additional Future Research Issues 

The following issues are relevant to future researeh efforts: 

a. HFSE Providing a Common Tool View 

What is the intelleetual load of having to learn the idiosynerasies of many 
different, ineompatible tool views? Eventually, a eonsistent integration layer may be 
needed for intelleetual manageability. The purpose of this layer would be to provide 
simplifieation and standardization of the tool user view. Some re-engineering may be 
needed. How do these issues relate to existing work? Does this reduee the size of this 
overall problem? 

b. Tool Replacement in the HFSE 

Is it possible to replaee one tool in the HFSE with another, while keeping 
the integrity of the HFSE? Given the inereasing longevity of software development 
efforts, it is likely that tools used to develop the early implementation of a software 
system will no longer be available deeades later while the software is still being 
maintained; what are the implieations to this for the HFSE? 

c. Tool Data Semantics 

Is it possible to exploit the greater degree of formalization and explieit 
semanties of data used by software tools to go further in automatie updating than was 
possible for Young in the eontext of data in military databases? 
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d. Specification Tradeoff Elasticity 

In software, when there is positive or negative eorrelation between 
speeifieations, how mueh trade-off in eapability is possible? What are appropriate 
software metries for establishing trade-offs and benehmarking? What are effeetive 
representations of "positive or negative eorrelations" in the eontext of supporting the 
tradeoffs? If QFD does not support these, what additional construets are needed? 

e. HFSE Data Representation 

What is the best medium for representation of information in the HFSE 
(e.g. tree strueture, hypergraph, ete.)? For what purposes is representation an issue? Is 
there a need to assume some eommon aspeets for all proeesses? Or is this part of the 
meta-proeess (the proeess of managing/improving the software development proeess)? 

f Interoperability Tradeoffs 

What is the tradeoff between interoperability via eonformanee to a single 
global data standard (e.g., VHSL for VLSI designs, step for meehanieal parts, ete.) versus 
using multiple representations, ontologies, and translations as supported by the FIOM 
approach? 

g. Data Standards and the HESE 

Can the needs of the HFSE be met by data standards? If not, what are the 
extra costs and benefits that ontologies provide? Eor example, type systems and 
inheritance rules differ from one programming language to another. Does this impact the 
required interoperability and integration of the models and tools? Does this issue require 
specific features and capabilities in the HESE? 

h. Dependency Paths and Constraints 

Do artifact dependencies always follow the step-to-artifact creation path? 
Are there instances in which the dependencies should follow portions of the path and not 
follow other portions of a path? Are there underlying constraints associated with the 
creation of a dependency? Can a dependency be any definable metric or must it be 
repeatable, ordered, and able to be deconstructed? Are there any other assumptions 
underlying dependencies? 
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L Method Tailoring 

Software Development Method Tailoring [FITZ03] is beeoming an 
important aetivity within software development, how ean the benefits of the HFSE be 
applied to this aetivity? 

j. Scalability of the HFSE Approach 

How sealable is the OOMI portion of the HFSE approaeh? As more and 
more tools are added to an HESE EIOM, does the overall federation eomplexity 
signifieantly degrade the usefulness of the approach? If so, are there ways to reduce this 
complexity (for instance, by totally reengineering the EIOM or by developing a second 
complementary EIOM)? 

k. Sensitivity Analysis 

What sensitivity analysis mechanisms can be added to the HESE to 
provide useful decision-support information associated with the subjective nature of the 
correlation and dependency valuations? 

D. CONCLUDING REMARKS 

Recall that challenge of "understanding" software from a holistic perspective 
formed a significant part of the motivation for this dissertation research. In several U.S. 
Government studies performed by Overton et. al. and presented in [PARI83], Overton 
found that there were three main factors which reduced the rate at which a software 
engineer can "understand" and decipher the intent and style of software written by 
another; the limited rate that a person can perceive clues in a mass of software artifacts, 
the human tendency to require more clues than are "logically" necessary in order 
understand, and the human tendency to be distracted and to procrastinate. As 
demonstrated in this dissertation research, the HESE provides a framework in which the 
"clues" are made more apparent to the software developer/maintainer. 

The research presented in this dissertation should be viewed as a first step into a 
larger and more complex investigation related to the application of the HESE to software 
development. While this dissertation demonstrated the feasibility of the approach, the 
larger research thread aims to actually improve software development process efficiency 
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and effectiveness by applying the HFSE in larger real-world contexts that will not only 
let software engineers work faster, but let them work smarter with greater understanding 
of customer desires and previous development work of the software development team. 
The HFSE was established by embedding the relevant portions of the Quality Function 
Deployment methodology into the already existing Relational Hypergraph Computer 
Aided Software Evolution model, then integrating this extended evolution model with a 
Federation Interoperability Object Model created from the tools and models use by the 
development team. Together, this framework provides an improved evolution-based, 
customer-focused holistic model upon which to develop safe, reliable software, produced 
on time and on budget that fully meets the Department of Defense and the nation’s 
software requirements. 
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GLOSSARY 


A 

Analytic Hierarchy Process (AHP): a statistical process developed by [SAAT80] whieh 
allows groups of hierarchieally struetured entities be valued in relation to eaeh other. 
Inereasing, AHP is used to assist in establishing valuations in the QFD proeess. 

Arcadia: a DARPA ISPE project in the early 1990’s consisting of validated research of 
numerous tools that relied on using an object management system and a software 
process language. 

atomic component: An atomic component is a component that cannot be decomposed 
into refined components [HARN99c]. 

atomic evolution step: An atomic evolution step is a step that cannot be decomposed 
into refined steps [HARN99c]. 

atomic evolutionary hypergraph: An atomic evolutionary hypergraph is an 
evolutionary hypergraph that cannot be decomposed into refined hypergraphs 
[HARN99C]. 

atomic SPIDER: It is an atomic step processed in different entrance relationships 
[HARN99C]. 

atomic step: An atomic step is a step that cannot be decomposed into refined steps 
[HARN99C]. 


C 

cardinality: A slot facet that describes whether the slot has just one value {single) or 
more than one value {multiple). In Protege-2000, Single is the default [PROTOSb]. 

classes tab: The Protege-2000 part used to create, view, revise, and save classes 
[PROTOSb]. 

clustering: an AHP technique by which non-independent components are “clustered” 
into independent groups for comparison. 

Component Class Representation (CCR): in the OOMI, the representation of a real 
world entity in a legacy system. 
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component management; Component management is one of CASES functions. In this 
function stakeholders can enter, delete, retrieve, modify, and query the attributes of 
atomic component from the hypertext database or software library (including 
software base and design database) [HARN99c]. 

component traceability: Component traceability is one of CASES functions. In this 
function an atomic component generated by its source atomic step can be traced not 
only by primary input which is the link between old version and new version atomic 
components, but also by a secondary input which is the link between source atomic 
step and components on which it depends, such as requirements and problem reports 
[HARN99C]. 

Component Trace View: in the HESE, a user-defined view in which a subgraph is 
induced from a single atomic component. The subgraph contains only those 
components connected to the component of interest. 

composite component; A composite component can be decomposed into refined 
components [HARN99c]. 

composite edge; A composite edge can be decomposed into refined edges in a 
hypergraph [HARN99c]. 

composite node: A composite node can be decomposed into refined nodes in a 
hypergraph [HARN99c]. 

composite step; A composite step can be decomposed into refined steps [HARN99c]. 

Computer-Aided Prototyping System (CAPS): CAPS is an easy to use, visual and 
integrated tool that can be used to rapidly design real-time applications using its 
PSDL editor, reusable software database, program generator, real-time scheduler, and 
so on [HARN99c]. CAPS has evolved into the prototyping suite known as 
SEATools. 

Computer Aided Resuscitation Algorithm (CARA): a real-world software system 
used to control the amount of intravenous fluid pumped to a battlefield casualty. 
CARA was used as a case study for the experiment conducted in this dissertation. 

Computer-Aided Software Evolution System (CASES): CASES is the automated tool 
support for the HESE. It provides an evolution environment in which software 
development artifact dependencies are captured and tracked. 

Consistency Index (Cl): defined by [SAAT80] for the AHP, the Cl is an intermediate 
calculation for measuring of the consistency a particular pair-wise comparison matrix 
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Consistency Ratio (CR): defined by [SAAT80] for the AHP, the CR is a measure of the 
eonsisteney a partieular pair-wise eomparison matrix. CR’s <0.1 are eonsidered 
aeeeptable. 

constraint management; Constraint management is one of CASES funetions. In this 
funetion the projeet organizer sets eonstraints that affeet the seheduling of steps, sueh 
as predeeessors, priorities, deadlines, estimated duration, earliest start times, finish 
times, as well as eonstraints that affeet personnel assignments, like seeurity level and 
skill requirements for a step [HARN99e]. 

Contextual Inquiry (Cl): A method used by Digital Corporation for gathering eustomer 
requirements by observing eustomers in their work environment. 

Coverage Analysis: a QFD teehnique for ensuring there are suffieient implementation 
eomponents (e.g. are there enough speeifieations for implementing all of the 
requirements). 

current component; A current component is a component a stakeholder is working on 
[HARN99C]. 

current step; A current step is a step a stakeholder is working on [HARN99c]. 

customer role; The roles of customers include system owners and end users 
[HARN99c]. 


D 

DARPA Agent Markup Language (DAML): a DARPA sponsored project in support of 
the Semantic-Web in which a series of ontologies are linked together to provide 
semantic interoperability between domains. 

dependency; The dependencies among software evolution objects are classified into four 
types; component-to-step, step-to-component, component-to-component, and step-to- 
step dependencies [HARN99c]. QFD dependencies (defined later) are a form of 
component-to-component dependencies. 

dependency management; Dependency management is one of CASES functions. In this 
function the dependencies among atomic components to an atomic step can be 
identified and managed [HARN99c]. 

Dependency Threshold View: in the HFSE, a user-defined view in which a subgraph is 
induced from a set of atomic components. The subgraph contains only those 
components with dependency values greater than (or less than) a particular user- 
specified threshold value. 
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deployment, deployed: a set of calculations for a set of QFD dependency values 
downstream (or upstream) in a software development effort. 

direct slot: A slot attached directly to a class (in contrast to a slot which is inherited) 
[PROTOSb], 

domain: A particular field of knowledge, such software engineering [PROTOSb]. 

downstream: in the direction of temporal creation of software artifacts (e.g. code is 
"downstream" of requirements (in the same development cycle)). 


E 

end user: The end user is a person who uses the software product and manipulate the 
software system [HARN99c]. 

Evolution Control System (ECS): The ECS provides automated assistance for the 
software evolution process in an uncertain environment where designer tasks and 
their properties are always changing. An ECS has two main functions. The first is to 
control and manage evolving software system components (version control and 
configuration management). The second is to control and coordinate evolution team 
interactions (planning and scheduling software evolution tasks, which they refer to as 
evolution steps) [HARN99c]. 

evolution history merging: Creating a new component based on two primary input 
components is called software evolution history merging [HARN99c]. 

evolution history splitting: Creating a new component in a variant different from the 
original variant is called software evolution history splitting [HARN99c]. 

evolutionary hypergraph: An evolutionary hypergraph is a labeled, directed, and 
acyclic hypergraph together with component and step attributes. The evolutionary 
hypergraph is a multi-level structure due to the refinement of the hyperedge 
[HARN99C]. 


F 

facets: The attributes of a slot. Some facets depend on the value of the type facet. For 
example, an integer slot type has facets for Minimum and Maximum [PROTOSb]. 

feature model: a coherent model of the common and variable properties of concepts 
(and their interdependencies) of a potential software system [CZAROO]. 
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Federation Entity (FE): the grouping of all FEVs for a single real-world entity. 

Together the FE eonstitutes the representation of a single real-world entity between 
all systems in the federation. 

Federation Entity View (FEV): a single relationship between a CCR and an ECR. 

Federation Interoperability Object Model (FIOM): the grouping of all EEs for a 

federation of interest. 

Federation Class Representation (FCR): the elass representation of a single entity at 
the federation level. 

forms tab: The Protege-2000 part used to ereate the forms for aequiring instanees of 
elasses. It may also be used to view, revise, and save the forms [PROTOSb]. 


G 

graph model (or graph data model): The graph model represents the evolution history 
as a direeted aeyelie graph G = [C, S, I, O] whieh is a bipartite with respeet to the 
edges / and O. To model the hierarehieal strueture of the evolution history, the graph 
model was modified to be a graph G = [C, S, CE, SE, I, O] [HARN99e]. 


H 

Holistic Framework for Software Engineering (HFSE): a eoneeptual framework for 
establishing interoperability between software development tools as well as a 
methodology (with tool support) that assembles the neeessary objeets and 
interoperability eonstruets for traeking and leveraging the dependeneies between 
development artifaets. 

hyperedge: The hyperedge is a multi-level strueture of the evolution step [HARN99e]. 

hypergraph: The hypergraph is a DAG (direeted aeyelie graph) with no looping paths 
[HARN990]. 

hypergraph model: The hypergraph model is introdueed to formalize the hierarehieal 
strueture of the evolution history in more detail [HARN99e]. 
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I 

inference rule management: Inference rule management is one of CASES functions. In 
this function the stakeholders can specify and adjust inference rules related to 
SPIDER formation, scheduling and assignment constraints, policies, special 
assignments, and so on, to help them resolve the design and management issues of the 
software development process [HARN99c]. 

inheritance: A parent-child (superclass-subclass) relationship between two classes. A 
child (subclass) inherits the slots of its parent classes (superclasses) [PROTOSb]. 

inherited slot: A slot that is attached to a class via inheritance from a parent class 
[PROTOSb]. 

input component: The input component to a current step is a set that combines a primary 
input component set and a secondary input component set [HARN99c]. 

input component search engine: The input component search engine can trace the 
dependencies among the software evolution components with the inference rules to 
find the input scope of the induced step [HARN99c]. 

instance (KB value): Concrete occurrence of information about a domain that is entered 
into a knowledge base. Eor example, Eran Smith might be an instance for a Name 
slot. An instances is entered via a form generated by Protege-2000 [PROTOSb]. 

instance (slot type): A type of slot whose value is the instance of a class [PROTOSb]. 

instances tab: The Protege-2000 part used to acquire instances of classes. It may also be 
used to view, revise, and save the instances [PROTOSb]. 

Integrated Computer Aided Software Engineering (I-CASE): a software 

development approach that relies on integrating a several CASE tools. 

Integrated Software Development Environment (ISDE): a software development 
approach providing common services and tools for multiple aspects of the software 
development effort. 

Integrated Software Project (or Programming) Environment (ISPE): a software 
development approach providing common services and tools for multiple aspects of 
the software development effort. The terms ISDE and ISPE are used interchangeably. 
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Issue-Based Information Systems (IBIS) model: IBIS model follows the prineiple that 
the design proeess for eomplex systems is fundamentally a eonversation among the 
stakeholders to resolve design issues. This model was extended to eneompass 
prototype demos, analysis, and design aetivities and applied to design a deeision 
support meehanism for software requirements engineering [HARN99e]. 


K 

Kano Model: the grouping of eustomer requirements into three broad areas: 1) Normal 
requirements — those requirements for whieh the eustomer reeeives proportional 
satisfaetion upon the delivery of funetionality meeting the requirements, 2) expeeted 
requirements — those requirements for whieh the eustomer is dissatisfied if the 
requirements fails to be fulfdled in the delivered software, and 3) exeiting 
requirements — those requirements for whieh the eustomer reeeives positive 
satisfaetion upon fulfillment. 

knowledge-acquisition tool: A tool used to build a knowledge base by aequiring 
instanees. In Protege-2000, the forms comprise the KA tool [PROTOSb]. 

knowledge base (KB): A set of instances of classes which may be used by PSMs 
[PROTOSb]. 

knowledge-based system: A computer system that includes a knowledge base about a 
domain and programs that include rules for processing the knowledge and for solving 
problems relating to the domain [PROTOSb]. 


M 

minimal hypergraph: A minimal hypergraph is a minimal unit of hypergraph whose 
edge set has only one edge [HARN99c]. 


Object-Oriented Model for Interoperability (OOMI): a model developed by 

[YOUN02b] which resolves modeling differences in a federation of independently 
developed heterogeneous systems, thus enabling system interoperation. 

OOMI Integrated Development Environment (OOMI IDE): a specialized toolset in 
support of the OOMI that is used to construct the FIOM. 
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ontology: A model of a particular field of knowledge - the concepts and their attributes, 
as well as the relationships between the concepts. In Protege-2000, an ontology is 
represented as a set of classes with their associated slots [PROTOSb]. 

output component; A step can generate one unique output component [HARN99c]. 


P 

.pins file: A Protege-2000 file in clips format that contains instances [PROTOSb]. 

.pout file: A Protege-2000 file in clips format that contains an ontology [PROTOSb]. 

.pprj file: A Protege-2000 file that contains a project. A project file contains the 
customized form information and references to external sources of the domain 
information [PROTOSb]. 

path; A path in the hypergraph is an evolution history whose components, including 
nodes and hyperedges, can be traced [HARN99c]. 

personnel management; Personnel management is one of CASES functions. In this 
function project managers control the current status of the project personnel such as 
skill, skill level, security level, on-hand jobs, and so forth [HARN99c]. 

primary-input-driven hyper graph; Each path in a primary-input-driven hypergraph is 
constructed by primary-input-driven path [HARN99c]. 

primary-input-driven path; If there exist an input node and an output node to an 
evolutionary hyperedge that are different versions of the same component then the 
path from the input node via the hyperedge to the output node is called a primary- 
input-driven path [HARN99c]. 

primary input component; If there exist an input component and an output component 
to a step that are different versions of the same component then the input component 
is called a primary input component [HARN99c]. 

primitive component; The primitive component that is a source component can not be 
produced by any step [HARN99c]. 

project evaluation; Project evaluation is one of CASES functions. In this function after 
project organizers propose an evolution step as a project, this project will be 
evaluated by project evaluators according to the possibility analysis of executing this 
software evolution step [HARN99c]. 
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project schema: a top-level evolutionary hypergraph which is an abstraction of the 
software development process being modeled within the HFSE. It is this abstraction 
which is first modeled within the CASES v2.0 drawing frame. 

project team: In CASES, there are three kinds of project teams: the project organization 
team, the system analysis team, and the system design team [HARN99c]. 

Prototype System Description Language (PSDL): PSDE is a specification language 
that is used in CAPS. PSDE provides graphical notation for dataflow diagrams 
enhanced with nonprocedural control timing constraints [HARN99c]. 

prototyping method: The prototyping process repeats a guess/check/modify cycle until 
the users agree that the demonstrated behavior is acceptable [HARN99c]. 


Q 

Quality Function Deployment (QFD): a requirements based methodology by which 
attributes of quality are deployed throughout a development effort. 

QFD correlation: a user specified value between two atomic components that represents 
the strength of relationship between the components. Typical QFD correlation 
schemes use 0:1:3:9 to represent the strength of relationship; however, a user may 
specify a different scheme to meet particular needs (even one that uses negative 
values). 

QFD dependency: a valued component attribute, which in combination with other 
dependency values can be “deployed” to other components. 

QFD dependency deployment: a set of calculations for a set of QFD dependency values 
downstream (or upstream) in a software development effort. 


R 

Random Index (RI): in AHP [SAAT80], RI is an empirically derived average of the 
consistency indices (CIs) of a set of randomly generated right, diagonal, reciprocal 
matrices. 

Rational Rose: a Rational Software Corporation software development tool that allows 
designers to model a software system using UME. 

Rational Requisite®Pro: a Rational Software Corporation software requirements 
management tool. 
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Rational Unified Process (RUP): a software engineering process, which espouses a 
disciplined approach to assigning tasks and responsibilities within a software 
development organization. Its goal is to ensure the production of high-quality 
software that meets the needs of its end-users, within a predictable schedule and 
budget. The RUP is also considered to be a process product, developed and 
maintained by Rational® Software [RATI98]. 

relational hypergraph; A relational hypergraph is an evolutionary hypergraph in which 
the dependency relationships between components and steps can have a hierarchy of 
specialized interpretations [HARN99c]. 

Relational Hypergraph Model (RH model); The RH model is a formal model for the 
software evolution which can help us develop tools to manage both the activities in a 
software development project and the products that those activities produce 
[HARN99C]. 

relational hypergraph net; The relational hypergraph net is a relational hypergraph 
which transfers a primary input hypergraph and secondary input hypergraphs into a 
top-level evolutionary hypergraph and an atomic evolutionary hypergraph. Therefore, 
a relational hypergraph net includes a top-level relational hypergraph net and an 
atomic level relational hypergraph net [HARN99c]. 

reusable software evolution component; The components can be reused in software 
evolution processes [HARN99c]. 


S 

secondary-input-driven hypergraph; Each path in a secondary-input-driven hypergraph 
is constructed by secondary-input-driven path [HARN99c]. 

secondary-input-driven path; If there exist an input node and an output node to an 
evolutionary hyperedge that are different components then the path from the input 
node via the hyperedge to the output node is called a secondary-input-driven path 
[HARN99C]. 

secondary input component; If there exist an input component and an output component 
to a step that are different components, then the input component is called a 
secondary input component [HARN99c]. 

slot: An attribute of a class. For example, a physician class might have name, title, and 
phone number as slots [PROTOSb]. 

slots tah: The Protege-2000 part that allows you to create, view, edit, and delete slots 
[PROTOSb]. 
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Software Development Life Cycle (SDLC); The SDLC model is called the waterfall 
model whose phases include requirements gathering, analysis, modeling or design, 
coding and testing [HARN99c]. 

Software Engineering Automation Tools (SEATools): the suite of software 
prototyping support tools developed at the Naval Postgraduate School. Evolved from 
CAPS and Distributed CAPS (DCAPS). 

Software Engineering Body of Knowledge (SWEBOK): an ongoing IEEE project 
devoted to providing a "consensually-validated characterization of the bounds of the 
software engineering discipline" [SWEBOl]. The SWEBOK categorizes the existing 
(and future) knowledge for the domain of software engineering; however, it does not 
attempt to define that knowledge. 

software evolution; We consider software evolution to include all the activities that 
change a software system, as well as the relationships among those activities 
[HARN99C]. 

software evolution component; Software evolution components include software and all 
of the components that are related to software evolution, such as criticisms, issues, 
requirements, specifications, modules, programs, optimizations, test scenarios, and 
stakeholders, within software evolution processes [HARN99c]. 

software evolution history (or evolution history); We use relational hypergraph to 
construct software evolution history [HARN99c]. 

software evolution management; We use dependency rules to manage software 
evolution objects [HARN99c]. 

software evolution object; Software evolution objects include software evolution steps 
and software evolution components [HARN99c]. 

software evolution process; Software evolution process includes software prototype 
evolution process and software product generation process [HARN99c]. 

software evolution step (or evolution step); Each software evolution step has an 
estimated task duration, deadline, priority, and a required skill level. Software 
evolution steps in software evolution process include; software prototype demo step, 
issue analysis step, requirement analysis step, specification design step, module 
implementation step, program integration step, software product demo step, and 
software product implementation step [HARN99c]. 

software evolution traceability; The issues of traceability in software evolution can be 
represented by paths of the hypergraph [HARN99c]. 
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software project; A software project is a project that can be built by the RH model, 
organized by project organizers, evaluated by project evaluators, and completed by 
system analysts and system designers [HARN99c]. 

Software Quality Function Deployment (SQFD): the QFD process applied to software. 

SPIDER; SPIDER denotes the Step Processed In Different Entrance Relationships 
[HARN99C]. 

Statistical Process Control (SPC): The removal of software defects through appraisals; 
logging and correcting customer complaints; completing software reviews, 
inspections, walkthroughs; and performing software testing. 

step management; Step management is one of CASES functions. In this function the 
content of the top-level step can be automatically generated, refined, and queried. The 
content of the atomic step can also be automatically generated, combined, and queried 
[HARN99C]. 

step refinement; Step refinement is one of CASES functions. In this function, the 
software evolution top-level step can be refined into a set of atomic steps 
[HARN99C]. 

Superfluous Artifact Analysis: an HESE analysis by which superfluous components 
(artifacts in the design that are not needed and have been erroneously introduced) are 
identified. 


T 

top-level evolution step; The top-level evolution step is the root step of an evolutionary 
hypergraph [HARN99c]. 

top-level evolutionary hypergraph; The top-level evolution hypergraph is the root of an 
evolutionary hypergraph [HARN99c]. 

top-level relational hypergraph net; A top-level relational hypergraph net is composed 
of a set of top-level SPIDERs. The top-level relational hypergraph net describes the 
relationships not only among each top-level step and its input and output nodes but 
also among each composite node and its subnodes [HARN99c]. 

top-level SPIDER; This is a top-level step processed in different entrance relationships 
[HARN99C]. 

type: A slot facet that identifies the kind of values a slot may have - Any, boolean, float, 
instance, integer, string, or symbol [PROTOSb]. 
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u 

upstream: against the direction of the temporal creation of software artifacts (e.g. 
requirements are "upstream" of specifications (in the same development cycle)). 


V 

variant: Variants represent alternative formulations of a software object with different 
objectives, such as running on different operating systems or serving different user 
communities [HARN99c]. 

version: A version of an object is one of the attributes of this object that can be 
represented as a string type containing the concatenation of an object identifier, a 
variant number, and a version number [HARN99c]. 

version control and configuration management: Version control and configuration 
management is one of CASES functions. In this function, a labeling function of 
CASES automatically determines the version and variation number of output 
components of a step. Software evolution process loops of CASES automatically 
construct the configuration management [HARN99c]. 
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APPENDIX A: CASES USE CASES 


A, INTRODUCTION 

This appendix provides the detailed uses cases for the Computer-Aided Software 
Evolution System (CASES) and provides a statement as to whether the use case has been 
implemented in CASESv2.0. These use cases were developed in support of this 
dissertation in order to appropriately identify the required system responses of the 
evolution tool support. Eigure 92 illustrates the context within which CASES operates. 


o 


Interoperability Engr 



Software Engr 

Figure 92 CASES Context Diagram 


As discussed in Chapter III, the Ontology Eibrarian is responsible for initially developing 
the federation and tool ontologies and entering them into Protege. Protege produces the 
XME Schemas for the EIOM which are imported into the OOMI IDE. Note that 
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CASES then imports these Java translators from the OOMI IDE so that it can track 
software evolution artifacts of subordinate tools in the HFSE federation. 


B. CASES TOP-LEVEL USE CASES 

Figure 93 illustrates CASES top-level use cases. Note that the six separate use 
cases address the functionality required by the CASES context diagram above (Figure 92) 



These use cases can be more fully stated as the following; 

1.0 Import translators from Babel. 

2.0 Software Engineer specifies Software Process to be used. 

3.0 Software Engineer specifies component Dependencies. 

4.0 Software Engineer registers components/steps to external tool artifacts/activities 
for automated tracking. 

5.0 CASES through middleware mechanism collects/tracks artifacts and activities. 

6.0 Software Engineer selects views of dependent artifacts. 

Each of these use cases is more fully explained in the remaining sections of the appendix. 
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C. USE CASE 1.0: IMPORT TRANSLATORS FROM BABEL 

The OOMI IDE generates Java translators that can be wrapped or embedded into 
middleware to translate XML documents generated by one system into XML documents 
that can used by another system. This use case delineates how CASES imports those 
translators so that they can be used for tracking specific artifacts between the two (or 
more) systems. Ligure 94 illustrates the use case and Table 49 provides a description of 
the user and system responses within the use case. 



Figure 94 Use Case 1,0: Import Translators from Babel 


# 

Actor 

System 

1 

The user selects "Import Translators" 
from the menu bar 

The system responds with a file 
browser pointed at the current directory 

2 

The user browses to the desired file 
location containing the java translators 
and selects the one(s) he wishes to 
import. 

The system loads the translators into 
the interoperability editor. 


Table 49 Actor-System Responses for Use Case 1,0 


This use case has not been implemented in CASESv2.0. 


D. USE CASE 2.0: SOFTWARE ENGINEER SPECIFIES SOFTWRE 

PROCESS 

One of the major shortcomings of previous versions of CASES was that the tool 
was specifically designed to work only with a single software development process 
model (the Evolutionary Prototyping Model). This dissertation provides an improvement 
over the previous versions by allowing software engineers to graphically define the 
software development process that they actually use, specifying the components 
(artifacts) that are produced in their process and the steps (activities) that they perform to 
create those components. Use case 2.0 is devoted to providing the engineer that 
functionality and is shown below in Eigure 95. 
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Figure 95 Use Case 2,0: Software Engineer Specifies Software Process 

Because this functionality is relatively complex, this use case has been 
decomposed into a number of more detailed cases as follows: 

2.1 Load existing software process. 

2.2 Create components and component attributes. 

2.3 Edit components and component attributes. 

2.4 Create steps and step attributes. 

2.5 Edit steps and step attributes. 

2.6 Move (rearrange) components and steps. 

2.7 Delete components and steps. 

2.8 Decompose components into subcomponents (e.g., Specifications 
SpecGroupl, SpecGroup2, etc.). 

2.9 Decompose steps (e.g., Analyze Requirements Establish Constraints + 
Formulate Questions + Formalize Requirements). 

The results of this use case (and its subordinate use cases) is that CASES provides a 

graphic view of the software process that the engineer uses and establishes directories for 

the accumulation of the actual software artifacts. 

1, Use Case 2.1: Load Existing Software Process (2 Scenarios) 

Use case 2.1 allows a software engineer to open an already existing software 

process model. An existing process model could be one that the engineer had already 

been using (scenario 1), or it could be a "template" for the start of refining his own 

specific process model (scenario 2). The Actor-System sequences for these two scenarios 

are shown in Table 50 and Table 51 respectively. 


# 

Actor 

System 

1 

The user selects "Open Existing 

Project Schema" 

The system responds with a file 
browser pointed at the current directory 

2 

The user browses to the desired 
existing project schemas and selects 
the one he wishes to use 

The system loads the project schema 
into the editor. 

3 

The user may then edit the schema as 
desired 

The system responds as per use cases 

2.2-2.9 


Table 50 Actor-System Responses for Use Case 2,1 (Scenario 1) 
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# 

Actor 

System 

1 

The user selects "Open Pre-Defined 
Project Schema" 

The system responds with a dialog that 
lists the available pre-defined project 
schemas (e.g. evolutionary prototyping 
model, waterfall model, spiral 
development model) 

2 

The user selects the desired schema 

The system responds with a "Save As" 
dialog. 

3 

The user saves the loaded schema as a 
new project 

The system creates new cfg, 
component, and step directories (all 
necessary project directories) in a 
folder with the name supplied by the 
user 

4 

The user may then edit the schema as 
desired 

The system responds as per use cases 

2.2-2.9 


Table 51 Actor-System Responses for Use Case 2.1 (Scenario 2) 


The use ease defined in Seenario 1 has been implemented in CASESv2.0; the use ease in 
Seenario 2 has not been implemented in CASESv2.0. 

2. Use Case 2.2: Create Components and Component Attributes 
Onee CASES has been started and either a new projeet has been ereated, pre¬ 
existing projeet opened, or a projeet schema template opened; the editing frame is then 
available for users to create components in the schema. Actually the engineer is creating 
an abstract container for the components (the artifacts) of their particular software 


development process. Table 52 lists the Actor-System responses for creating components 
within CASES. 


# 

Actor 

System 

1 

The user selects the "component" 
button from the Project Schema tool 
bar. 

The system responds by activating the 
cursor to allow the user to place 
"components" within the drawing 
frame. 

2 

The user places a component on the 
drawing frame by clicking the left 
mouse button. 

The system draws a named circle on 
the drawing frame. Initially, the name 
is a unique default component 
identifier. 

The system resets the cursor to allow 
the placement of additional 
components. 


Table 52 Actor-System Responses for Use Case 2.2 
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This use case (use case 2.2) has been implemented in CASESv2.0. 

3. Use Case 2,3: Edit Components and Component Attributes (2 
Scenarios) 

After the user has created components within the project schema drawing frame, 
he can then edit the attributes of those components through two different means 
illustrated in the Actor-System responses shown in Table 53 and Table 54. 


# 

Actor 

System 

1 

After selecting the "select" button on 
the Project Schema tool bar, the user 
double clicks on an established 
component 

The system responds by displaying the 
component attribute dialog. 

2 

The user edits the attribute fields in 
the dialog: 

• Component ID: a unique 
component identifier 

• Component Name: a 50 character 
string 

• Component Description: a 250 
character text field 

The system reports an error (and 
prevents the user from exiting the 
dialog) if the user attempts to create a 
component with an ID that is identical 
to an existing component 

The system stores the component 
attributes. 

The system renames the component 
file in accordance with the component 
ID. 


Table 53 Actor-System Responses for Use Case 2,3 (Scenario 1) 
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# 

Actor 

System 

1 

After seleeting the "seleet" button on 
the Projeet Sehema tool bar, the user 
right elieks on an established 
eomponent. 

The system offers the user an extended 
menu of the following: 

• Properties 

• Deeompose 

• Delete 

• QFD 

• Import CSV File 

2 

The user seleets "Properties" 

The system responds by displaying the 
eomponent attribute dialog. 

3 

The user edits the attribute fields in 
the dialog. 

• Component ID; a unique 
eomponent identifier 

• Component Name: a50eharaeter 
string 

• Component Deseription: a 250 
eharaeter text field 

The system reports an error (and 
prevents the user from exiting the 
dialog) if the user attempts to ereate a 
eomponent with an ID that is identieal 
to an existing eomponent 

The system stores the eomponent 
attributes. 

The system renames the component 
file in aeeordanee with the eomponent 
ID. 


Table 54 Actor-System Responses for Use Case 2,3 (Scenario 2) 


Both scenarios of use ease 2.3 have been implemented in CASESv2.0. 

4, Use Case 2.4: Create Steps and Step Attributes 

In mueh the same way that the user ereated the eomponents, the user ean ereate 
steps for the projeet sehema. The Aetor-System responses for the use ease are shown in 
Table 55. 
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# 

Actor 

System 

1 

The user selects the "step" button from 
the Project Schema tool bar. 

The system responds by activating the 
cursor to allow the user to draw "steps" 
between exiting components within the 
drawing frame. 

2 

The user draws a step by left clicking 
once on an existing component and 
then left clicking a second time on 
another component. 

The system draws a named line on the 
drawing frame between the two 
components. Initially, the name is a 
unique default step identifier. 

The system resets the cursor to allow 
the placement of additional steps. 


Table 55 Actor-System Responses for Use Case 2.4 


This use case (use case 2.4) has been implemented in CASESv2.0. 

5. Use Case 2,5: Edit Steps and Step Attributes (2 Scenarios) 

After the user has created steps within the project schema drawing frame, he can 
then edit the attributes of those steps through two different means illustrated in the Actor- 


System responses shown in Table 56 and Table 57. 


# 

Actor 

System 

1 

After selecting the "select" button on 
the Project Schema tool bar, the user 
double clicks on an established step. 

The system responds by displaying the 
step attribute dialog. 

2 

The user edits the attribute fields in 
the dialog. 

• Step ID; a unique step identifier 

• Step Name: a 50 character string 

• Step Description; a 250 character 
text field 

The system reports an error (and 
prevents the user from exiting the 
dialog) if the user attempts to create a 
step with an ID that is identical to an 
existing step. 

The system stores the step attributes. 

The system renames the step file in 
accordance with the step ID. 


Table 56 Actor-System Responses for Use Case 2,5 (Scenario 1) 
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# 

Actor 

System 

1 

After selecting the "select" button on 
the Project Schema tool bar, the user 
right clicks on an established sten. 

The system offers the user an extended 
menu as follows: 

• Properties 

• Decompose 

• Delete 

• QED 

• Import CSV Pile 

2 

The user selects "Properties" 

The system responds by displaying the 
step attribute dialog. 

3 

The user edits the attribute fields in 
the dialog. 

• Step ID; a unique step identifier 

• Step Name: a 50 character string 

• Step Description: a 250 character 
text field 

The system reports an error (and 
prevents the user from exiting the 
dialog) if the user attempts to create a 
step with an ID that is identical to an 
existing step. 

The system stores the step attributes. 

The system renames the step file in 
accordance with the step ID. 


Table 57 Actor-System Responses for Use Case 2.5 (Scenario 2) 


Both scenarios of use ease 2.5 have been implemented in CASESv2.0 

6, Use Case 2,6: Move (Rearrange) Components 

Onee placed on the drawing frame, the user ean move components around within 
the project schema. Table 58 describes the Actor-System responses for use case 2.6. 


# 

Actor 

System 

1 

After selecting the "select" button on 
the Project Schema tool bar, the user 
single clicks and holds onto an 
established component. The user 
drags the component to a new desired 
location. 

The system responds by visually 
cueing the user that the component has 
been selected (e.g. outlines the 
component in bold). 

Then the system drags the component 
to the new location designated by the 
user. Any step lines attached to the 
"moved" component will also move 
along with the component. 


Table 58 Actor-System Responses for Use Case 2.6 


With the exception of providing a visual cue (bold outline), this use case (use case 2.6) 
has been implemented in CASESv2.0. 
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7. Use Case 2.7: Delete Components and Steps (2 Scenarios) 

The user can delete components and steps by two different means as described by 
the Actor-System responses in Table 59 and Table 60 below. 


# 

Actor 

System 

1 

After selecting the "select" button on 
the Project Schema tool bar, the user 
right clicks on an established 
component or step. 

The system offers the user an extended 
menu as follows: 

• Properties 

• Decompose 

• Delete 

• QFD 

• Import CSV File 

2 

The user selects "Delete" 

The system responds with a "Do you 
really want to Delete?" dialog. 

3 

The user selects either "Delete" or 
"Cancel" 

If the user selects "Delete", the 
component (and any steps connected to 
the component) or step is deleted. 



The system deletes all appropriate fdes. 



If the user selects "Cancel", then the 
system closes the dialog without 
deleting the item. 


Table 59 Actor-System Responses for Use Case 2.7 (Scenario 1) 
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# 

Actor 

System 

1 

After selecting the "select" button on 
the Project Schema tool bar, the user 
selects an established component or 
step with a single left mouse click. 

The system responds by visually 
queuing the user that the component 
has been selected (e.g. outlines the 
component in bold). 

2 

The user presses the "Delete" button 
on the keyboard. 

The system responds with a "Do you 
really want to Delete?" dialog. 

3 

The user selects either "Delete" or 
"Cancel" in the dialog. 

If the user selects "Delete", the 
component (and any steps connected to 
the component) or step is deleted. 

The system deletes all appropriate fdes. 

If the user selects "Cancel", then the 
system closes the dialog without 
deleting the item. 


Table 60 Actor-System Responses for Use Case 2.7 (Scenario 2) 


Neither of the scenarios of use case 2.7 has been implemented in CASESv2.0. It is 
currently not possible to delete components; instead, the user must reconstruct the project 
schema. 


8. Use Case 2.8: Decompose Components into Subcomponents 

After the user has placed components on the drawing frame, he can then 
decompose a particular component into subcomponents (e.g.. Specifications 
Specification Group 1, Specification Group2, etc.). Actor-System responses for this use 
case are described in Table 61. 
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# 

Actor 

System 

1 

After selecting the "select" button on 
the Project Schema tool bar, the user 
right clicks on an established 
component. 

The system offers the user an extended 
menu as follows: 

• Properties 

• Decompose 

• Delete 

• QED 

• Import CSV Pile 

2 

The user selects "Decompose" 

The system responds with a new 
drawing frame. 

Existing input and output steps from 
the "parent" component are 
automatically placed into the new 
drawing frame with an "External" label 
at the appropriate end. 

3 

The user continues to define the 
software development process in 
accordance with use cases 2.2 - 2.9 

The system updates the "parent" 
component attributes. 

The system provides a visual queue 
that the component is decomposable 
(double circle). 

e-g- 


Table 61 Actor-System Responses for Use Case 2.8 


Use case 2.8 has not been implemented in CASESv2.0. 

9. Use Case 2.9: Decompose Steps 

The user has the ability to decompose steps into a sequence of atomic steps and 
components (e.g., “Analyze Requirements” becomes (Establish Constraints 
Constraints Eormulate Questions Questions Eormalize Requirements-^ Eormal 
Requirements)). The Actor-System responses are described in Table 62. 
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# 

Actor 

System 

1 

After selecting the "select" button on 
the Project Schema tool bar, the user 
right clicks on an established sten. 

The system offers the user an extended 
menu as follows: 

• Properties 

• Decompose 

• Delete 

• QFD 

• Import CSV File 

2 

The user selects "Decompose" 

The system responds with a new 
drawing frame. 

Existing input and output components 
from the "parent" step are 
automatically placed into the new 
drawing frame. 

3 

The user defines the additional more 
detailed description of the step of the 
software development process in 
accordance with use cases 2.4 - 2.7 
and 2.9 by adding steps and 
components. 

The system updates the "parent" step 
attributes. 

The system provides a visual queue 
that the step is decomposable (double 
line). 

Dev Spec 

e.g. 


Table 62 Actor-System Responses for Use Case 2.9 


Use case 2.9 has not been implemented in CASESv2.0. 


E. USE CASE 3.0: SOFTWARE ENGINEER SPECIFIES COMPONENT 
DEPENDENCIES 

After the software engineer has constructed the project schema that lays out the 
software development process that he is using, the next step is to specify those 
dependencies that he wishes to "deploy" throughout the development effort. This use 
case is shown below in Figure 96. 
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Figure 96 Use Case 3,0: Software Engineer Specifies Component Dependencies 

This use case is then further decomposed into several more detailed use cases as follows; 

3.1 Create dependency (establish type of dependency and dependency attributes). 

3.2 Establish dependency linkages between components. 

3.3 Deploy dependency through the development effort. 

The result of this set of use cases is that the system provides the user the ability to define 
a particular dependency. The user can then edit the relationships between components 
and set specific values for the dependency related to specific components within a QFD 
matrix structure. The user can then "deploy" the dependency to the next component by 
clicking the "calculate" button or throughout the entire development effort by clicking the 
"synchronize" button. 

1, Use Case 3.1: Create Dependency 

In this use case the user establishes type of dependency and defines dependency 


attributes. The Actor-System responses are described below in Table 63 


# 

Actor 

System 

1 

The user selects the "Create 
Dependency" menu item. 

The system displays the "New 
Dependency" dialog. 

2 

The user inputs attributes for the new 
dependency as follows; 

• Short Name 

• Description 

• Dependency Type (e.g. Risk, 

Safety, Parent/child, etc.) 

• Dependency Value Range (if 
applicable — Boolean, 1-9, +/-, 1/3/9, 
based on QFD Methodology) 

• Dependency Default Value 

• The origin component of the 
dependency 

The system stores the attributes. 


Table 63 Actor-System Responses for Use Case 3,1 
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Only a portion of this use case (use case 3.1) has been implemented in CASESv2.0. The 
“Dependency Type” and “Dependency Value Range” currently have no functionality in 
the system. These entries exist in the creation dialog, but currently serve no purpose. 


2, Use Case 3,2: Establish Dependency Linkages Between Components 
(2 Scenarios) 

After creating a dependency, the user can then edit the dependency values and the 
correlation between components that the dependency is to be "deployed across." There 
are two scenarios for establishing the correlations. In Scenario 1, the engineer defines 
dependencies between different artifacts (e.g. R1 S3). In scenario 2 the user 
establishes dependencies between the same type of component (e.g., R1 R3.2). The 


Actor-System responses for these two scenarios are described in Table 64 and Table 65 
respectively. 


Actor 


System 


After selecting the 
"select" button on the 
Project Schema tool 
bar, the user right 
clicks on an 
established step. 


The system offers the user an extended menu as follows: 

• Properties 

• Decompose 

• Delete 

• QFD 

• Import CSV File 


The user selects 
"QFD" and further 
selects the particular 
dependency that he 
wants to edit. 


The system produces a QFD matrix rectangular matrix. 

Inside the matrix are correlations between the two 
components. The value of the dependency is the default 
value specified in the create dependency dialog or an 
imported value. The initial correlation value in the matrix 
is set to "0". A color (e.g. yellow) is used to indicate 
which values the user has not yet edited as follows: 




Sped 

Spec2 

Spec3 






Reql 

1 

0 

0 

0 

Req2 

4 

0 

3 

0 

Req3 

3 

0 

0 

0 

Req4 

4 

0 

1 

0 


The user edits values 
of dependency and 
correlation 


The system records the values and saves them to file. 


Table 64 Actor-System Responses for Use Case 3,2 (Scenario 1) 
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# 

1 


Actor _ 

After selecting the "select" button on 
the Project Schema tool bar, the user 
right clicks on an established 
component. 


System _ 

The system offers the user an extended 
menu as follows: 

• Properties 

• Decompose 

• Delete 


2 


The user selects "QFD" and further 
selects the particular dependency that 
he wants to edit. 


• QFD 

• Import CSV File _ 

The system produces a QFD matrix 
rectangular matrix. 


Inside the matrix are correlations 
between the same components. The 
default value of the dependency is the 
default value specified in the create 
dependency dialog. The initial 
correlation value in the matrix is set to 
"0". A color (e.g. yellow) is used to 
indicate which values the user has not 
yet edited. A different color (e.g. red) 
is used to indicate un-needed 
correlations between the same set of 


components as 

ollows: 



Reql 

Req2 

Req3 



1 

4 

3 

Reql 

1 

0 

0 

0 

Req2 

4 

0 

0 

0 

Req3 

3 

0 

0 

0 


3 


The user edits values of dependency 
and correlation. 


The system records the values and 
saves them to file. 


Table 65 Actor-System Responses for Use Case 3,2 (Scenario 2) 


Except for the use of color-coding to cue the user as to which entries have been edited, 
use case 3.2 Scenario 1 has been implemented in CASESv2.0. Use Case 3.2 Scenario 2 
ahs been implemented; however, this scenario currently serves no function. Eventually, 
Scenario 2 will be used to establish trade-offs between the same type of components. 
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3. Use Case 3,3: Deploy Dependency Through the Development Effort 
(2 Scenarios) 

After creating a dependency, correlation values, and dependency values, the user 
can deploy the dependency across components. There are two scenarios for deploying 


the dependency shown in Table 66 and Table 67. 


# 

Actor 

System 

1 

After the user has edited all desired 
values of dependency and correlation, 
he selects the "Calculate" button on 
the QFD dialog. 

The system automatically calculates the 
appropriate value of dependency for the 
deployed component and displays those 
values in the QFD dialog 


Tahle 66 Actor-System Responses for Use Case 3.3 (Scenario 1) 


# 

Actor 

System 

1 

After the user has edited all desired 
values of dependency and correlation, 
he selects the "Synchronize" button on 
the tool bar. 

The system automatically calculates the 
appropriate values of dependency for all 
QFD matrices in the system. The 
appropriate values of the dependency 
are displayed the next time the user 
opens a particular QFD dialog. 


Table 67 Actor-System Responses for Use Case 3,3 (Scenario 2) 


Both scenarios of Use Case 3.3 have been implemented in CASESv2.0. 

F. REGISTER COMPONENTS AND STEPS TO EXTERNAL TOOL 
ARTIFACTS AND ACTIVITIES 

The project schema created in use case 1.0 is an abstract representation of artifacts 
created in the software development effort. Use Case 4.0 allows CASES to import data 
about real artifacts in other software tools so that dependencies between these artifacts 
can be established and tracked. Figure 97 below illustrates this use case. 



Figure 97 Use Case 4,0: Register Components and Steps to External Tool Artifacts and 

Activities 
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This use case is further decomposed into three subordinate use cases as follows: 

4.1 Map Components to Tool Objects. 

4.2 Map Steps to Tool Activities/Methods. 

4.3 Insert Translators. 

The result of this set of use cases is that CASES shows a graphic view of the components 
and the tool objects to which they correspond. It also shows a graphic view of the steps 
and the tool activities and methods to which they correspond and embeds OOMI 
translators into middleware so that appropriate interoperability translation can take place. 

1. Use Case 4.1: Map Components to Tool Objects 

In this use case the user imports a Comma Separated Value (CSV) fde into 
CASES. This CSV file contains lists of data associated with real artifacts produced in 


other tools. The Actor-System response for this use case is described in Table 68. 


# 

Actor 

System 

1 

After selecting the "select" button on 
the Project Schema tool bar, the user 
right clicks on an established sten. 

The system offers the user an extended 
menu as follows: 

• Properties 

• Decompose 

• Delete 

• QED 

• Import CSV Pile 

2 

The user selects "Import CSV Eile" 

The system responds with a file 
browser pointed at the current directory 

3 

The user browses to the desired CSV 
file and selects the one he wishes to 
map against that particular set of 
components 

The system loads the CSV file into 
component directory. 


Table 68 Actor-System Responses for Use Case 4.1 


Use Case 4.1 has been implemented in CASESv2.0. However, once Use Cases 4.2 and 

4.3 are implemented (in future versions of CASES), this use case should be re-written to 
take advantage of the middleware mechanism being used. 

2. Use Case 4.2: Map Steps to Tool Activities/Methods 
In this use case, the user identifies actual method calls between tools so that as 
artifacts are created, CASES con monitor that creation and automatically and 
dynamically update the list and values of components (artifacts). This use case has not 
been implemented in CASESv2.0. 
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3, Use Case 4,3: Insert Translators 

In this use case, the user automatically inserts the OOMI IDE supplied translators 
into the CASES middleware ORB and registers them against external tool objects 
identified in other tool ORBs. This use case has not been implemented in CASESv2.0. 

G. USE CASE 5.0: CASES THROUGH MIDDLEWARE MECHANISM 
COLLECTS/TRACKS ARTIFACTS AND ACTIVITIES 

CASES monitors and tracks the creation, modification, and deletion of artifacts 

throughout the software development life cycle. Artifacts and dependencies are 

automatically updated. Eigure 98 illustrates this use case and Table 69 describes the 

Actor-System responses. 




SW Development Tools 


Figure 98 Use Case 5,0: Register 


# 

Actor 

System 

1 

Through CASES, user launches 
Software Development tool (e.g. 

Word, ReqPro, CAPS, etc.) 

The tool opens. 

2 

The user uses the tool. 

The tool (through the middleware) 
publishes changes to created artifacts. 

The system (CASES) tracks the 
changes to created artifacts. 

The system (CASES) translates 
appropriate artifacts and passes them to 
other launched tools. 


Table 69 Actor-System Responses for Use Case 5,0 


This use case, although defined, is not implemented in CASESv2.0. As of now, all 
tracking is done through the importing of static data files (i.e. .csv files). The files can be 
created as often as a user desires, but the process is not yet dynamic. 
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H, USE CASE 6.0: SELECT VIEWS OF ARTIFACT DEPENDENCIES 

In this particular use case the software engineer can define particular views of 
artifact dependencies. In essence the engineer is taking a "slice" of the underlying 
hypergraph representation of the software development effort. This slice is tailored to the 
specific set of artifacts and dependencies that the user specifies. Figure 99 below 
illustrates the use case. 



SW Engineer 


Figure 99 Use Case 6,0: Select Views of Artifact Dependencies 

This use case is further decomposed into subordinate use cases as follows: 

6.1 Software Engineer selects a view based on single dependency link (e.g. R S, 
thus you get the house or roof of the QFD matrix). 

6.2 Software Engineer selects a view based on single component (e.g. S1.2 ^ entire 
induced subgraph backed out from SI.2). 

6.3 Software Engineer selects a view based on a threshold dependency value for a 
particular type of dependency (e.g. Risk threshold > mean + 1 standard 
deviation entire induced subgraph where risk >ju + <j ) 

The results of this use case will provide the software engineer three different means of 

obtaining decision support information about the software development effort 

1, Software Engineer Selects a View Based on Single Dependency Link 


(2 Scenarios) 


In this use case the engineer can view the QFD matrix (either "house" or "roof) 
for any set of components. Table 70 describes the Actor-System responses for viewing 
the QFD "house" for two different types of components and Table 71 describes the 
Actor-System responses for viewing the QFD "roof for the same type of components. 
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# 

1 


Actor _ 

After selecting the "select" button on 
the Project Schema tool bar, the user 
right clicks on an established step. 


System _ 

The system offers the user an extended 
menu as follows: 

• Properties 

• Decompose 

• Delete 


The user selects "QFD" and further 
selects the particular dependency that 
he wants to view. 


• QFD 

• Import CSV File _ 

The system produces a QFD matrix 
rectangular matrix. 

Inside the matrix are correlations 
between the two components and 


values of t 

he dependencies as follows: 



Sped 

Spec2 

Spec3 



1.57 

5.52 

2.89 

Reql 

1 

0 

0 

9 

Req2 

3 

0 

3 

0 

Req3 

4 

0 

3 

0 

Req4 

2 

3 

0 

1 


Table 70 Actor-System Responses for Use Case 6,1 (Scenario 1) 
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# 

1 


Actor _ 

After selecting the "select" button on 
the Project Schema tool bar, the user 
right clicks on an established 
component. 


System _ 

The system offers the user an extended 
menu as follows: 

• Properties 

• Decompose 

• Delete 


2 


The user selects "QFD" and further 
selects the particular dependency that 
he wants to view. 


• QFD 

• Import CSV File _ 

The system produces a QFD matrix 
rectangular matrix. 


Inside the matrix are correlations 
between the same components. The 
value of the dependency is displayed, 
A color (e.g. red) is used to indicate 
un-needed correlations between the 
same set of components as follows: 




Reql 

Req2 

Req3 



1 

4 

3 

Reql 

1 

0 

1 

3 

Req2 

4 

0 

0 

0 

Req3 

3 

0 

0 

0 


Table 71 Actor-System Responses for Use Case 6,1 (Scenario 2) 


Both scenarios of Use Case 6.1 have been implemented in CASESv2.0. 

2, Use Case 6,2: Software Engineer Selects a View Based on Single 
Component 

In this use case the user identifies a particular component and threshold 
correlation value (e.g. SI.2 threshold 2^ entire induced subgraph backed out from SI.2 
where correlations > 2). The system then identifies and displays all connected 
components with correlation values greater than that threshold. Table 72 describes the 
Actor-System responses. 
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# 

Actor 

System 

1 

With a QFD matrix open, the user 
selects "Trace" from the dialog 
"View" menu. 

The system responds by providing a 
"Trace" dialog 

2 

The user selects the component to be 
traced from and the threshold 
correlation value 

The system responds by providing 
"culled" QFD matrices related to each 
step that show only those connected 
components with correlation values 
greater than the threshold. 

These components represent a "slice" 
of the underlying hypergraph that are 
connected to the selected component 
with a correlation greater than the 
selected threshold. 


Table 72 Actor-System Responses for Use Case 6,2 


Use Case 6.2 has been implemented in CASESv2.0. 

3. Use Case 6,3: Software Engineer Selects a View Based on a Threshold 
Dependency Value for a Particular Type of Dependency 

In this use ease the user identities a particular type of dependency and a threshold 
value. The system then displays all components with dependency values greater or equal 
to than (or less than or equal to) that threshold value (e.g. Risk threshold > mean + 1 
standard deviation entire induced subgraph where risk >ju + a ). Table 73 describes 
the Actor-System responses for this use case. 
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# 

Actor 

System 

1 

With a QFD matrix open to a 
partieular type of dependeney, the user 
seleets "User-Defined" from the dialog 
"View" menu. 

The system responds by providing a 
"User-Defined" dialog 

2 

The user seleets the amount of the 
standard deviation (from the mean) 
and whether he is interested in the 
values "greater than or equal to" or 
"less than or equal to" that threshold 

The system responds by providing a 
"eulled" QFD matrix that shows only 
those eomponents with a dependeney 
value that satisfies the threshold 
eriteria. 

These eomponents represent a "sliee" 
of the underlying hypergraph that meet 
the user's threshold eriteria. 


Table 73 Actor-System Responses for Use Case 6,3 


Use Case 6.3 has been implemented in CASESv2.0. 
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APPENDIX B: CARA INFUSION PUMP REQUIREMENTS FROM 

REQUISITE PRO 


A. INTRODUCTION 

Section B of this appendix provides a listing of the requirements of the CARA 
Infusion Pump [WRAI02a] specified within Requisite®Pro. The requirement numbers 
and descriptions (Feature Tag and Requirement Text) come directly from [WRAI02c]i; 
the requirement names were derived from the general description of the requirement. 
The values for AHP Priority, Requirements Clarity, and Safety were artificially derived 
and created as user defined Requisite®Pro requirements attributes in order to provide 
meaningful data for the software experiment delineated in this dissertation. “AHP 
Priority” values are requirement priority values calculated using the Analytic Hierarchy 
Process [SAAT80] and then multiplied by 500 (AHP values typically sum to 1). 
Requirements clarity values are integer values based on the number and applicability of 
questions posed by developers about individual requirements; the higher the value, the 
less clear is the requirement (i.e. a high value indicates that a number of clarifying 
questions had to be asked about a particular requirement). Safety values are assigned on 
a 1 to 5 scale with 1 being low safety impact to the design and 5 being high safety impact 
to the design. 

B. CARA REQUIREMENTS SPECIFIED IN REQUISITE®PRO 


FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEATl 

CARA On 

The CARA will be operational 
whenever the LSTAT is 
powered on. 

1.169 

3 

1 


^ Reprinted with permission of the Walter Reed Army Institute of Research, Dr. Stephen A. Van 
Albert, May 2003. 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT2 

Pump Status 
Display 

The display will show a 
message indicating the current 
status of the pump. One of the 
following indications will 
appear: 

1.403 

0 

2 

FEAT2.1 

Not Plugged 

In 

The pump is not plugged in 

1.123 

0 

2 

EEAT2.2 

Plugged In 

Status 

Unknown 

The pump is plugged in and its 
operational status is unknown 

1.123 

0 

2 

EEAT2.3 

Plugged In 
Manual Mode 

The pump is plugged in and is 
running in manual mode 

1.123 

0 

2 

EEAT2.4 

Plugged In 
but Stopped 

The pump is plugged in and is 
stopped 

1.123 

0 

2 

EEAT2.5 

Plugged In 

Auto-Control 

Mode 

The pump is plugged in and is 
operating in auto-control mode 

1.123 

0 

2 

EEAT3 

Monitor 

Pump 

CARA will monitor the pump 
connector on the ESTAT to 
determine when a pump is 
plugged in 

7.016 

9 

2 

EEAT4 

Pump 

Deteeted Msg 
Display 

When the pump is detected an 
appropriate message will be 
displayed. 

7.016 

0 

2 

EEAT5 

Pump 

Detected 

Timestamp 

When the pump is detected a 
timestamp will be entered into 
a resuscitation file. 

7.016 

0 

3 

EEAT6 

Continuity 

Check 

Upon connection CARA will 
continuously check continuity 
on all wires going to the pump. 

1.403 

13 

2 

EEAT6.1 

Discontinuity 

Message 

Display 

If a discontinuity is detected 
on any lines, CARA will 
display appropriate messages. 

1.403 

7 

2 

EEAT6.2 

Discontinuity 

Alarm 

If a discontinuity is detected 
on any lines, CARA will issue 
appropriate alarms. 

1.754 

7 

4 

EEAT6.3 

Discontinuity 
Terminate AC 

If a discontinuity is detected 
while in auto-control, CARA 
will terminate auto-control 

2.456 

16 

5 

EEAT7 

Occlusion 

Eine 

Monitoring 

The CARA will monitor the 
occlusion lines whenever the 
pump is plugged in. 

1.052 

0 

3 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT7.1 

Occlusion 

Detected 

If an oeelusion fault is 
deteeted 

1.052 

0 

3 

FEAT7.1.1 

Oeelusion 
Display Msg 

An appropriate error message 
should is issued. 

1.052 

0 

2 

EEAT7.E2 

Oeelusion 
Eevel 1 

Alarm 

A level 1 alarm should is 
issued 

1.754 

3 

4 

EEAT7.E3 

Oeelusion 
Terminate AC 

If an oeelusion is deteeted 
while in auto-eontrol, CARA 
will terminate auto-eontrol 

2.105 

9 

5 

EEAT8 

Air OK 
Monitoring 

The CARA will monitor the 

Air OK line whenever the 
pump is plugged in. 

1.403 

12 

2 

EEAT8.1 

Air OK 
Remains Eow 

If the Air OK signal remains 
low for 10 seeonds 

1.052 

4 

3 

EEAT8.E1 

AirOK Msg 
Display 

An appropriate error message 
should is issued. 

1.052 

4 

2 

EEAT8.E2 

AirOK Eevel 

1 Alarm 

A level 1 alarm should is 
issued 

1.403 

7 

4 

EEAT8.E3 

AirOK 

Terminate AC 

If an air fault is deteeted while 
in auto-eontrol, CARA will 
terminate auto-eontrol 

2.105 

13 

5 

EEAT9 

EMF 

Monitoring 

CARA should monitor the 
baek EMF line from the pump 
to keep traek of infused fluids 
by polling immediately when 
the pump is plugged in and 
then on every even 5-seeond 
eloek interval while the pump 
remains plugged in. 

2.339 

19 

2 

EE AT 10 

Baek EMF 
Deteeted in 
Manual Mode 

If baek EMF is deteeted in 
manual mode the volume 
infused should be ealeulated 
(Manual mode is defined as 
the time when the pump is 
eonneeted to the ESTAT and 
is infusing fluid into a patient 
using the hardware flow 
setting on the pump.) 

2.806 

0 

2 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEATlO.l 

Log 

Cumulative 

Volume 

The eumulative volume 
infused from the time of 

CARA initialization should be 
logged into the resuseitation 
file with the time every minute 
on the minute while the pump 
is plugged in. 

2.806 

24 

3 

FEAT10.2 

Graph Trend 

Cumulative 

Volume 

The volume infused should be 
trended on a graphieal display 
every minute 

1.403 

9 

2 

EE AT 11 

Caleulate 

Flow Rate 

The flow rate should be 
ealeulated from the baek EMF 
on every 

1.169 

9 

2 

EEATll.l 

Display Flow 
Rate 

The flow rate should be 
displayed eontinuously with 
the display being updated with 
every new reading. 

2.689 

3 

2 

EEATll.1.1 

EMF 

Unobtained 
Flow Rate 
Unknown 

If the EMF reading eannot be 
obtained, the display should 
indieate that the flow rate is 
unknown. 

2.222 

12 

2 

EEAT11.2 

Flow Rate 
Logged 

The average flow rate for the 
past minute should be written 
to the resuseitation file onee 
per minute on the minute 
while the pump is plugged in. 

2.339 

13 

3 

EEAT 11.2.1 

Unknown 
Flow Rate 
Logged 

If the EMF reading eannot be 
obtained the log entry should 
indieate that the average flow 
rate is unknown for the 
minute. 

1.637 

16 

3 

EEAT 11.2.2 

EMF 

Unobtained or 
Zero, 

Terminate AC 

If the EMF reading eannot be 
obtained or is zero while in 
autoeontrol, CARA will 
terminate auto-eontrol 

1.637 

16 

5 

EEAT 12 

EMF Present, 
Fog Manual 
Mode 

If baek EMF is present, the 
faet that the pump is in manual 
mode should also be reeorded 
in the resuseitation file 

2.806 

0 

3 

FEAT12.1 

Display 
Manual Mode 

The faet that the pump is in 
manual mode should also be 
shown on the display. 

1.871 

0 

2 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT 13 

BPs Various 
Sources 

The CARA should be able to 
use a blood pressure from 
various sourees as the input 
into the CARA algorithm. 
Blood pressure sourees 
(arterial line, euff, other 
noninvasive pressures [pulse 
wave transmission, ete.]) will 
be prioritized based on quality. 

1.169 

3 

3 

FEAT13.1 

Corroborated 

A-line 

Priority 1 

A eorroborated A-line is use 
priority 1 

4.677 

9 

3 

EEAT13.2 

Corroborated 
Pulse Wave 
Priority 2 

A eorroborated pulse wave 
pressure is use priority 2 

3.508 

9 

2 

EEAT13.3 

Cuff Pressure 
Priority 3 

A euff pressure is use priority 

3 

2.339 

9 

1 

EEAT14 

Manual 

Model Eog 

BP 

If the CARA deteets a blood 
pressure during manual mode, 
it should log the pressure (both 
systolie and diastolie values) 
to the resuseitation file every 
minute on the minute, 
eoineident with any other 
logging that is oeeurring on 
the minute. 

2.339 

0 

2 

EEAT14.1 

Avg BP 
Logged 

If the souree reports the blood 
pressure more than onee a 
minute, an average over the 
minute should be stored into 
the resuseitation file. 

2.572 

0 

2 

EEAT14.1.1 

BP Souree 
Logged 

Along with the blood pressure, 
the souree of the BP should be 
reeorded into the resuseitation 
file 

1.871 

0 

2 

EEAT14.1.2 

BP Time 
Logged 

The time of the BP should be 
reeorded into the resuseitation 
fide. 

2.572 

0 

2 

EEAT14.1.3 

BP Display 
w/ Infused 
Volume 

The blood pressure that is 
stored to file should also be 
graphed on the same display as 
the infused volume 

1.169 

9 

2 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT14.1.4 

BP Value on 
Display 

The numerieal value of the 
blood pressure should be 
displayed as well. 

1.169 

0 

2 

FEAT 15 

Respond to 
Eost BP 
Sources 

During resuseitation CARA 
should respond to any lost 
blood pressure sourees 

2.105 

27 

4 

FEAT15.1 

Display Msg, 
Eost BP 
Source 

With an appropriate message 

3.508 

3 

2 

FEAT 15.2 

Eevel 1 

Alarm, Eost 
BP Souree 

With a level 1 alarm 

4.911 

18 

4 

FEAT15.3 

Fogged, Eost 
BP Souree 

With a notation in the 
resuseitation file 

3.508 

3 

3 

FEAT 16 

CARA Ready 
for AC 

When CARA determines that 

1) a pump is plugged in and 
not stopped, 2) an infusate 
with an impedanee within 
toleranee is in plaee, and 3) the 
oeelusion line is elear. 

0.327 

0 

2 

FEAT16.1 

Display AC 
Ready 

The display will show a 
"CARA Status OK" message 
indieating that CARA is ready 
to start auto-eontrol and a Start 
Auto-eontrol button. 

1.473 

0 

2 

FEAT 16.2 

Display Mean 
BP 

The display will also show the 
default mean blood pressure of 
70 mmHg to whieh CARA 
will titrate. 

1.473 

0 

2 

FEAT 16.3 

Set Point 
Button 

The user will have the ability 
to inerease or deerease the set 
point by pressing a "ehange set 
point" button. 

2.292 

0 

2 

FEAT 16.4 

Change Set 
Point Dialog 

Pressing the "ehange set point" 
button will display a ehange 
set point dialog with five 
buttons: "up", "down", and 
"OK" "Caneel" and "Default". 

2.292 

0 

2 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT 16.5 

Change Set 
Point 

Onee the "ehange set point" 
dialog is aetive, the proposed 
set point will be displayed 
within the dialog box and ean 
be inereased or deereased by 
pushing an "up" or a "down" 
button. 

0.655 

3 

2 

FEAT 16.5.1 

Set Point 
Inerement 

Eaeh press will ehange the set 
point by 5 mmHg. 

0.655 

1 

2 

FEAT 16.5.2 

Set Point 
Eimits 

The set point will have limits 
of 60 - 120 mmHg. 

0.655 

1 

2 

FEAT16.5.3 

Set Point OK 
button 

Pressing the OK button will 
aetivate the set point and elose 
the dialog and display the set 
point button 

0.982 

9 

2 

FEAT 16.5.4 

Fog Set Point 
Change 

When a set-point ehange is 
aetivated the ehange will be 
reeorded to the log fde. 

0.655 

1 

2 

FEAT16.5.5 

Set Point 
Caneel Button 

Pressing the Caneel button will 
elose the dialog box and leave 
the set point unehanged. 

0.327 

1 

2 

FEAT16.5.6 

Set Point 
Default 

Button 

Pressing the Default button 
returns the proposed set point 
to the default in the dialog 
box. 

0.982 

1 

2 

FEAT 16.6 

Set Point 

Changes 

Anytime 

The set point ean be ehanged 
at any time during 
resuseitation. 

2.292 

0 

2 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT 16.7 

Set Point 

Dialog 

Visabilty 

The change set point button 
and change set point dialog 
box will not be available when 
any other dialog box is open 
(TAC or Override). If the set 
point button or dialog is 
removed because another 
higher priority dialog box was 
displayed, it will be displayed 
and made available again 
when the higher priority dialog 
boxes have been closed. 
However, if auto control is 
terminated while the set point 
dialog is "hidden", it will not 
be redisplayed. 

1.31 

18 

2 

FEAT 17 

AC Button 
Selected 

If the 'Start Auto-control' 
button is selected. 

1.403 

0 

4 

FEAT 17.1 

AC Initial 
Flow Rate 

The CARA will initialize the 
pump at a default flow rate of 

4 l/hr. 

3.274 

0 

4 

FEAT 17.2 

AC Inflate 
Cuff 

Upon entering auto-control 
mode CARA will inflate the 
blood pressure cuff. 

1.637 

9 

3 

FEAT17.3 

AC Cuff Not 
Available 

If cuff pressures are not 
available 

0.702 

0 

3 

FEAT17.3.1 

AC Cuff Not 
Avail Msg 

An appropriate message 
should be displayed. 

0.935 

0 

2 

FEAT17.3.2 

AC Cuff Not 
Avail Eevel 1 
Alarm 

A level 1 alarm is issued 

0.935 

3 

4 

FEAT17.3.3 

AC Cuff Not 
Avail 

Override 

Buttons 

An override "yes" button and 
an override "no" button will 
then be displayed. 

0.935 

4 

2 

FEAT17.3.3.1 

AC Cuff Not 
Avail 

Override Yes 
Button 

Pressing the override "yes" 
button will force the CARA to 
use the top priority (req. 13) 
uncorroborated pressure 
source for control. 

0.702 

4 

3 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT17.3.3.1.1 

AC Cuff Not 
Avail 

Override No 
Button 

Pressing the "no" button will 
return to manual mode. 

0.702 

7 

3 

FEAT17.3.3.2 

AC Cuff Not 
Avail 

Override 

Logged 

A notation should be entered 
in the resuseitation file as to 
the button pushed. 

1.403 

1 

3 

EEAT17.3.4 

AC Cuff Not 
Avail Alarm 
Reset 

Pressing the alarm reset button 
will remove the audible and 
visual alarm and reattempt to 
inflate the euff 

0.935 

9 

4 

EEAT17.4 

AC Initiating 
Logged 

A notation should be made in 
the resuseitation file, 'initiating 
auto-eontrof 

1.637 

9 

3 

EEAT17.5 

AC Initiating 
Displayed 

A notation should be made to 
the display, 'initiating auto- 
eontrof 

1.403 

12 

2 

EEAT17.6 

No Available 
BPs Revert to 
Manual Mode 

If euff pressure is not available 
and there are no other blood 
pressures sourees available 
CARA should revert to manual 
mode 

3.508 

3 

5 

EEAT17.6.1 

No Available 
BPs Revert to 
Manual Mode 
Display 

An appropriate message 
should be displayed. 

1.637 

0 

2 

EEAT17.6.2 

No Available 
BPs Revert to 
Manual Mode 
Alarm and 

Log 

A level 1 alarm is issued 
(logged to fide and displayed) 

1.637 

3 

4 

EEAT18 

Valid BP 
Range 

Mean pressure readings from 
the Propaq must be within 40 - 
150 mmHg to be valid 
throughout resuscitation. 

7.016 

33 

2 

EEAT19 

No Propaq 
Data Stream 

If the CARA does not receive 
the data stream from the 

Propaq 

1.403 

9 

2 

EEAT19.1 

No Propaq 
Data Stream 
Display 

An appropriate message 
should be displayed. 

1.403 

0 

2 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT19.2 

No Propaq 
Data Stream 
Eevel 2 

Alarm 

A level 2 alarm should be 
issued 

1.871 

3 

3 

FEAT20 

BP 

Corroboration 

Begins 

Onee the 'Start Auto-eontrol' 
button has been pressed, BP 
souree eorroboration begins in 
the order of source priority 
(req. 13), if a cuff pressure is 
available 

0.935 

3 

3 

EEAT20.1 

BP 

Corroboration 

Souree 

Control 

A source control pressure will 
be compared to a 
corresponding cuff pressure 

1.684 

0 

3 

EEAT20.2 

BP 

Corroboration 

Souree 

Control 

Within 10% 

If the source pressure is with 
in 10% of the corresponding 
cuff pressure the source in 
corroborated and will be used 
for control 

1.684 

0 

3 

EEAT20.3 

BP 

Corroboration 

Souree 

Control Not 
Within 10% 

If the source pressure is not 
with in 10% of the 
corresponding cuff pressure, 
two more cuff readings will be 
taken and compared to 
corresponding source readings 

0.561 

0 

3 

EEAT20.3.1 

BP 

Corroborated 

If both source pressure 
readings are within 10% of the 
corresponding cuff readings, 
the source is corroborated and 
will be used for control 

0.561 

0 

3 

EEAT20.3.2 

BP 

Corroboration 

Failure 

Dialog 

If both source pressure 
readings are not within 10% of 
the corresponding cuff 
readings, an override dialog 
box will be displayed and the 
corroboration failure will be 
logged. 

0.561 

9 

2 

EEAT20.3.2.1 

BP 

Corroboration 

Failure 

Dialog Yes 
Button 

If the override "YES" button is 
pressed, the uncorroborated 
source will be used for control 

0.561 

0 

2 
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Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT20.3.2.2 

BP 

Corroboration 

Failure 

Dialog No 
Button 

If the override "NO" button is 
pressed, CARA will attempt to 
eorroborate the next priority 
souree (req. 13) based on 
readings already eolleeted 

0.561 

0 

2 

FEAT20.3.2.2.1 

BP 

Corroboration 
Failure Cuff 
for Control 

If no other source is available, 
CARA will use the cuff 
pressure for control. 

0.748 

0 

2 

EEAT20.3.2.2.2 

BP 

Corroboration 

Failure 

Additional 

Attempts 

Uncorroborated blood 
pressures sources will be 
compared to each cuff reading. 
If the readings are within 10% 
the CARA will automatically 
switch over to the new source. 
Override dialog boxes will not 
be displayed for these 
subsequent corroboration 
attempts. 

0.748 

9 

2 

EEAT20.4 

BP 

Corroboration 
Cuff for 
Control 

During source corroboration, 
CARA will use the cuff 
pressure for control 

1.123 

3 

3 

EEAT20.5 

Display 

Control 

Souree 

CARA should display the 
blood pressure control source 
(e.g. Arterial Fine, Pulse 

Wave, Cuff, etc.) 

1.123 

3 

2 

EEAT20.6 

Fog Control 
Souree 

CARA will log the blood 
pressure control source to the 
log fde 

0.935 

0 

3 

EEAT20.7 

Re- 

eorroborate 

Interval 

CARA will re-corroborate the 
blood pressure control source 
with the cuff every 30 minutes. 

0.935 

24 

2 

EEAT20.7.1 

Re- 

eorroborate 

Wait 

Condition 

Any active corroboration 
attempt must be completed 
before the periodic 30-minute 
re-corroboration can begin. 

0.935 

24 

2 

EEAT20.7.2 

No Cuff for 
Re-ealibration 

If the cuff pressure is not 
available for re-calibration. 

0.748 

4 

2 

EEAT20.7.2.1 

No Cuff for 

Re-ealibration 

Display 

An appropriate message 
should be displayed 

0.748 

2 

2 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT20.7.2.2 

No Cuff for 
Re-calibration 
Eevel 1 

Alarm 

A level-1 alarm should be 
issued 

0.748 

2 

4 

FEAT20.8 

Higher BP 

Source 

Available 

If a higher priority blood 
pressure source than the one 
that CARA is using becomes 
available, CARA should 
corroborate the higher priority 
blood pressure source using 
the current blood pressure 
source. 

1.684 

12 

3 

EEAT20.8.1 

Higher BP 
Source 
Available 
Deconfliction 

If a source is in the process of 
being corroborated, or an 
override question is pending 
and a new higher priority 
source begins reporting, 
corroboration of the new 
higher priority source cannot 
begin until the current 
corroboration process 
complete or the override 
question is answered. 

1.123 

18 

2 

EEAT21 

Deleted Rqt 

Deleted Rqt 

0 

0 

0 

EEAT22 

Deleted Rqt 

Deleted Rqt 

0 

9 

0 

EEAT23 

A-Eine Not 
Available 

If an arterial line is not 
available then other blood 
pressure sources should be 
used. 

7.016 

9 

3 

EEAT24 

Pulse Wave 
Available 

If the pulse wave signal is 
detected. 

0.935 

2 

3 

EEAT24.1 

Pulse Wave 
Calibration 

CARA should immediately 
begin to calibrate the pulse 
wave using an average of 3 
cuff pressures taken one 
minute apart. It is expected 
that a valid pulse wave 
pressure reading will be 
available every 15 seconds for 
control purposes. To be used, 
the pulse wave must be 
calibrated using the cuff 
pressure. 

1.754 

5 

3 
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Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT24.2 

Pulse Wave 

Re-ealibration 

Interval 

The pulse wave should be re- 
ealibrated every 15 minutes 
using the average of two euff 
pressures taken one minute 
apart. 

1.403 

2 

3 

FEAT24.3 

Pulse Wave 
Re-ealibration 
w/ No Cuff 

If the euff pressure is not 
available for re-ealibration, 

1.403 

2 

3 

EEAT24.3.1 

Pulse Wave 
Re-ealibration 
w/ No Cuff 
Display 

An appropriate message 
should be displayed. 

0.935 

2 

2 

EEAT24.3.2 

Pulse Wave 
Re-ealibration 
w/ No Cuff 
Eevel 1 

Alarm 

A level 1 alarm is issued 

1.754 

5 

4 

EEAT24.3.3 

Use East 

Good Pulse 
Wave 

The CARA should eontinue 
using the pulse wave with the 
last good ealibration. 

1.754 

2 

3 

EEAT25 

Only Cuff to 
be Used 

If only a euff pressure is to be 
used the CARA should 
immediately initiate 5 blood 
pressure readings one minute 
apart. 

1.754 

0 

3 

EEAT26 

CARA Re¬ 
adjust after 
Eaeh New BP 

The CARA will readjust after 
eaeh blood pressure reading. 

7.016 

0 

3 

EEAT27 

Cuff As 
Control 
Interval 

When the euff pressure is 
being used for eontrol, CARA 
should set a euff reading 
frequeney based on a table. In 
general, blood pressures will 
be taken more frequently while 
below the set point. If the euff 
is already inflating for some 
other reason when the time 
arrives for another reading, an 
additional euff reading does 
not need to be requested. 

1.871 

15 

3 
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Requirement Text 

AHP 
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Rqts 

Clarity 

Safety 

FEAT27.1 

Cuff As 
Control 
Interval, BP 

60 or Below 

If the mean BP is 60 or below, 
euff pressures will be taken 
onee per minute. 

1.871 

10 

3 

FEAT27.2 

Cuff As 
Control 
Interval, BP 
(60-70] 

If the mean BP is (60 - 70], 
euff pressures will be taken 
onee every 2 minutes. 

1.871 

10 

3 

EEAT27.3 

Cuff As 
Control 
Interval, BP 
(70-901 

If the mean BP is (70 - 90], 
euff pressures will be taken 
onee every 5 minutes. 

1.871 

10 

3 

EEAT27.4 

Cuff As 
Control 
Interval, BP 
Above 90 

If the mean BP is above 90, 
euff pressures will be taken 
onee every 10 minutes. 

1.871 

10 

3 

EEAT28 

No Valid BP 
in 3 Minutes, 
Revert to 
Manual Mode 

If CARA ean not obtain a 
valid blood pressure in 3 
minutes, it should revert baek 
to manual mode. 

3.742 

6 

4 

EEAT28.1 

No Valid BP 
in 3 Minutes, 
Revert to 
Manual Mode 
Display 

An appropriate message 
should be displayed 

2.806 

1 

2 

EEAT28.2 

No Valid BP 
in 3 Minutes, 
Revert to 
Manual Mode 
Eevel 2 

Alarm 

A level 2 alarm should be 
issued. 

2.806 

3 

3 

EEAT29 

Caleulate 
Pump Voltage 

Onee a valid blood pressure 
has been established the 

CARA should ealeulate a 
voltage to drive the pump. 

7.016 

0 

5 

EEAT29.1 

Display AC 
Mode 

A notation indieating that the 
system is in auto-eontrol mode 
should be made on the display 

1.403 

0 

2 

EEAT29.2 

Eog AC 

Mode 

A notation indieating that the 
system is in auto-eontrol mode 
should be made in the 
resuseitation file. 

2.806 

0 

3 
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AHP 
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Rqts 
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Safety 

FEAT29.3 

Display BP 

Set Point for 
AC Mode 

Also, a horizontal line 
indieating the blood pressure 
set point should be shown on 
the graphieal display. 

2.806 

0 

2 

FEAT30 

New Voltage 
Interval 

When using an arterial line, 
pulse wave or other beat-to- 
beat blood pressure a new 
voltage should be ealeulated 
every 15 seeonds by the 

CARA. 

7.016 

0 

4 

EEAT30.1 

New Voltage 
Interval for 
Cuff 

When using the euff pressure a 
new eontrol voltage should be 
established after every blood 
pressure reading. 

7.016 

0 

3 

EEAT31 

Minimum 
Flow Rate 

The CARA will always 
maintain at least a KVO flow 

rate. 

14.032 

9 

5 

EEAT32 

BP Souree 

Change 

Monitoring 

CARA will always monitor for 
blood pressure souree ehanges 

2.339 

0 

3 

EEAT32.1 

Corroborate 

Higher 

Priority 

Souree 

If the new souree is a higher 
priority souree than the eurrent 
eontrol souree (req. 13) the 
new souree will be 
eorroborated (req. 20) 

2.923 

0 

3 

EEAT32.E1 

Use New 

Corroborated 

Souree 

If the new souree is 
eorroborated, CARA should 
ehange to use the new souree 
for control 

4.093 

0 

3 

EEAT32.E2 

Not 

Corroborated 

Override 

Dialog 

If the new source is not 
corroborated, an override 
dialog should be displayed to 
give an opportunity to change 
to the uncorroborated higher 
priority source, as described in 
req. 20. An override alert is 
issued at this time also (an 
alarm). 

2.339 

0 

3 

EEAT33 

Deleted Rqt 

Deleted Rqt 

0 

9 

0 

EEAT34 

Terminate AC 

Button 

Availability 

When the CARA is in auto¬ 
control mode a 'Terminate 
Autocontrof button should be 
made available. 

16.37 

9 

5 
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FEAT35 

Deleted Rqt 

Deleted Rqt 

0 

9 

0 

FEAT36 

Deleted Rqt 

Deleted Rqt 

0 

9 

0 

EEAT37 

Deleted Rqt 

Deleted Rqt 

0 

9 

0 

EEAT38 

Deleted Rqt 

Deleted Rqt 

0 

15 

0 

EEAT39 

Ealling BP 
Monitoring 

CARA should monitor for 
falling blood pressure 

4.677 

33 

4 

EEAT39.1 

Ealling BP 
Display 

An appropriate message 
should be displayed 

3.508 

10 

2 

EEAT39.2 

Falling BP 
Eevel 2 

Alarm 

A level 2 alarm should be 
issued. 

3.508 

13 

3 

EEAT40 

Deleted Rqt 

Deleted Rqt 

0 

12 

0 

EEAT41 

Deleted Rqt 

Deleted Rqt 

0 

18 

0 

EEAT42 

Eost BP in 

AC Mode 

While in auto-eontrol mode, if 
a beat-to-beat blood pressure 
signal is lost for more than 1 
minute 

2.339 

0 

4 

EEAT42.1 

Eost BP in 

AC Mode 
Display 

An appropriate message 
should be displayed 

2.339 

0 

2 

EEAT42.2 

Eost BP in 

AC Mode 
Eevel 1 

Alarm 

A level-1 alarm should sound 

2.806 

0 

4 

EEAT42.3 

Eost BP in 

AC Mode 
Graphieal 
Display 
Notation 

Notation should be made on 
the graphieal display. 

1.871 

0 

2 

EEAT43 

Beat-to-Beat 
Signal Eoss 

If the beat-to-beat signal is lost 
for more than 3 minutes 

1.871 

3 

4 

EEAT43.1 

Beat-to-Beat 
Signal Loss 
Display 

An appropriate message 
should be displayed 

0.935 

1 

2 

EEAT43.2 

Beat-to-Beat 
Signal Loss 
Level 2 

Alarm 

A level 2 alarm should sound 

1.871 

4 

3 

EEAT43.3 

Beat-to-Beat 
Signal Loss 
Drive Voltage 
Setting 

The drive voltage should be 
set to the last good blood 
pressure 

2.806 

1 

5 
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AHP 
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Rqts 

Clarity 

Safety 

FEAT43.4 

Beat-to-Beat 
Signal Eoss 
Revert to 
Seeondary BP 
Souree 

CARA should then revert to 
using seeondary blood 
pressure sourees using 
appropriate quality eontrol 
proeedures. 

2.806 

3 

3 

FEAT44 

Cuff BP 

Invalid 

Reading 

If only the euff pressure is 
being used and an expeeted 
blood pressure reading is 
invalid 

1.169 

9 

3 

EEAT44.1 

Cuff BP 
Invalid 
Reading 
Display 

An appropriate message 
should be displayed 

1.169 

3 

2 

EEAT44.2 

Cuff BP 

Invalid 

Reading 

Eevel 1 

Alarm 

A level-1 alarm should sound 

2.105 

3 

4 

EEAT44.3 

Initiate New 
Cuff BP 
Reading 

CARA should then initiate 
another request for a euff 
pressure. 

1.169 

3 

3 

EEAT44.3.1 

If New Cuff 
BP Invalid 

If this pressure is invalid, 

0.585 

3 

3 

EEAT44.3.1.1 

If New Cuff 
BP Invalid 
Display 

An appropriate message 
should be displayed 

1.169 

3 

2 

EEAT44.3.1.2 

If New Cuff 
BP Invalid 
Eevel 2 

Alarm 

A level-2 alarm should sound 

1.403 

3 

3 

EEAT44.3.1.3 

If New Cuff 
BP Invalid 
Revert to 
Manual Mode 

The system will revert to 
manual mode 

1.52 

12 

5 

EEAT44.4 

Eog Cuff BP 
Invalid 

Notations should be made to 
the resuseitation file 

1.403 

3 

3 

EEAT45 

Alarm 

Deseription 

Alarms eonsist of an audible 
alarm and a visual alarm 
message. When an alarm 
beeomes aetive, the audible 
alarm sounds and the alarm 
message is plaeed on the 
display. 

0.655 

3 

4 
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Rqts 
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FEAT45.1 

Alarm Msg 
Priority 

Alarm messages will be listed 
aeeording to alarm priority as 
deseribed in the alarm table. 

1.146 

10 

4 

FEAT45.1.1 

Alarm 

Message 

Deseription 

The alarm messages should be 
in the form of direetions to the 
earegiver on how to fix the 
problem. If multiple options 
are available to fix the 
problem, then all fixes should 
be listed in priority in a single 
message on the display. 

1.637 

10 

3 

EEAT45.2 

Aetive 

Alarms When 
Pump Un¬ 
plugged 

If the pump is unplugged 
while any alarms are aetive, 
the aetive alarms should be 
automatieally reset. Only the 
pump-unplugged alarm will 
remain or beeome aetive if 
appropriate. 

1.473 

4 

3 

EEAT45.3 

Alarm Reset 
When 
Condition 
Resolved 

Alarms will automatieally be 
reset and the alarm message 
will be removed if CARA 
deteets that the alarm 
eondition has been resolved. 

1.473 

4 

3 

EEAT45.4 

Alarm 

Buttons 

Two "soft" buttons will appear 
whenever there is an alarm. 

One button will allow 
temporary sileneing of the 
alarm for a set period. The 
other button will be an 
"Aeknowledge/reset" button. 

0.819 

5 

3 

EEAT45.4.1 

Silenee 

Alarms button 

Caregiver should have the 
ability to silenee the audio 
alarm while fixing the problem 
by pressing the "silenee 
alarms" button. 

0.819 

7 

3 

EEAT45.4.E1 

Silenee 

Alarms 

Period 

The alarm should be sileneed 
only for a period of time. Time 
period depends on the nature 
of the problem as deseribed in 
the alarm table. 

1.146 

7 

4 
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FEAT45.4.1.2 

Silence 

Alarms 

Display 

The alarm message should 
remain on the display when 
the temporary silence button is 
pushed. 

1.146 

13 

4 

FEAT45.4.1.3 

Silence 

Alarms Not 
Resolved 

If the alarm condition is not 
fixed and time expires, then 
the audible alarm should sound 
again. 

1.146 

13 

4 

EEAT45.4.2 

Alarm 

Acknowledge 
/Reset Button 

Once the caregiver has 
executed the desired fix, he 
will push the 

Acknowledge/Reset button 
(this is necessary only for 
conditions that must be polled 
by the CARA system) 

0.655 

7 

3 

EEAT45.4.2.1 

Fault Fixed 

TS Timer 
Disabled 

If the fault is fixed, then the 
alarm will be completely reset 
and the temporary silence 
"TS" timer will be disabled. 

1.31 

5 

4 

EEAT45.4.2.2 

Fault Not 
Fixed, Alarm 
Repeat 

If the fault is not fixed, the 
audible alarm will 
immediately sound and the 
visual portion of the alarm will 
continue and the message will 
stay on the display. The 
temporary alarm silence timer 
will be removed. 

1.31 

31 

4 

EEAT45.5 

No Permanent 
Alarm Off 
Function 

There shall be no software 
provision for turning the 
alarms off permanently. 

1.637 

4 

4 

EEAT46 

All Alarms 
Logged 

All alarms will be recorded in 
the resuscitation file 

3.742 

0 

3 

EEAT46.1 

All Alarms 
Fogged with 
time 

The time issued will be 
recorded 

2.806 

0 

3 

EEAT46.2 

All Alarm 
Resets 

Fogged with 
Time 

The time reset will be recorded 

2.806 

0 

3 

EEAT47 

Pump 
Unplugged 
Fogged with 
Timestamp 

If the pump is unplugged an 
entry should be made to the 
log file with a timestamp. 

1.403 

12 

3 


303 




FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT47.1 

When No 
BackEME 

While there is no back EMF 
detected 

0.819 

4 

3 

FEAT47.1.1 

When No 

BaekEME 

Display 

The system should display an 
appropriate message. 

1.403 

4 

2 

EEAT47.2 

When No 

BaekEME 

Detected 

While back EMF is detected 

0.819 

4 

2 

EEAT47.2.1 

When No 
BackEME 
Detected 
Display 

A message on the display 
should appear 

1.988 

4 

2 

EEAT47.2.2 

When No 

BackEME 

Detected 

Eevel 1 

Alarm 

A level 1 alarm should be 
issued 

2.339 

8 

4 

EEAT47.3 

Pump 
Unplugged 
during AC 

During auto-control mode, 

0.585 

12 

3 

EEAT47.3.1 

Deleted Rqt 

Deleted Requirement 

0 

12 

0 

EEAT47.3.2 

Deleted Rqt 

Deleted Requirement 

0 

12 

0 

EEAT47.3.3 

Pump 
Unplugged 
during AC, 
Terminate AC 

CARA should exit auto¬ 
control mode 

2.339 

13 

5 

EEAT48 

Terminate AC 
Selected 

Whenever the 'Terminate auto- 
control' button is selected the 
auto-control termination 
sequence begins. 

1.286 

3 

5 

EEAT48.1 

Deleted Rqt 

Deleted Requirement 

0 

9 

0 

EEAT48.2 

Terminate AC 

Confirmation 

Message 

A confirmation message 
indicating that control will be 
released should be displayed in 
a dialog box. This dialog box 
will take priority over all other 
open dialogs. Any other open 
dialog boxes will be closed 
when the Terminate Auto¬ 
control dialog box is 
displayed. 

3.859 

3 

2 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT48.3 

Terminate AC 
Yes 

Confirmation 

Button 

A eonfirmation yes button will 
be displayed 

2.572 

0 

3 

FEAT48.3.1 

Terminate AC 
Yes 

Confirmation 

Button 

Seleeted 

Pressing this button will 
relinquish fiow eontrol of the 
pump. The pump will operate 
at its hardware switeh setting. 

5.145 

0 

5 

EEAT48.3.E1 

Terminate AC 
Yes 

Confirmation 

Button 

Seleeted 

Display 

A notation that the system is in 
manual mode should be made 
to the display 

2.572 

0 

2 

EEAT48.3.E2 

Terminate AC 
Yes 

Confirmation 

Button 

Seleeted 

Logged 

A notation that the system is in 
manual mode should be made 
to the resuseitation file. 

5.145 

0 

3 

EEAT48.4 

Terminate AC 
No 

Confirmation 

Button 

A eonfirmation no button will 
be displayed. 

1.286 

0 

2 

EEAT48.4.1 

Terminate AC 
No 

Confirmation 

Button 

Seleeted 

Pressing the this button will 
return the system to Auto- 
eontrol, elosing the Terminate 
auto-eontrol dialog box, and 
re-opening the highest priority 
pending dialog box, if any 
exist. 

1.286 

0 

3 

EEAT48.5 

Terminate AC 
Confirmation 
Dialog, 
Change Set 
Point Button 

While the eonfirmation dialog 
box is displayed, the Change 
Set Point button should be 
disabled if it is available, and 
the Alarm rest button should 
be disabled if it is available. 

2.572 

18 

3 

EEAT49 

Aetion Button 
Aetion 

When an aetion button is 
pressed the button should be 
made unavailable (removed or 
disabled). 

7.016 

9 

2 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT50 

Interrupt 

Signals 

Logic level input signals 
(Pump connection, continuity. 
Occlusion) will occur as an 
interrupt signal when the state 
of a signal changes. 

7.016 

0 

2 

FEAT51 

Clock 

Interrupts 

A clock interrupt must trigger 
certain events at even five- 
second and 60-second clock 
intervals after the pump is 
plugged in. 

2.105 

6 

2 

EEAT5E1 

5 Second 

Clock 

Interrupts 

At the five-second interval the 
sequence of events should be 
to check EMF, display the 
updated flow rate, and then 
check impedance value. 

2.806 

9 

2 

EEAT5E2 

60 Second 

Clock 

Interrupts 

At the 60-second interval the 
sequence of events should be 
to check EMF, display the 
updated flow rate, check the 
impedance value, write the 
flow rate, cumulative volume 
infused and impedance value 
to the log file. 

2.806 

9 

2 

EEAT52 

Impedance 

Polling 

Sequence 

The impedance will be polled 
immediately after the EMF 
when the pump is plugged in 
and then on every even 5- 
second interval while the 
pump remains plugged in. 

2.385 

34 

2 

EEAT52.1 

Impedance 
Value Eogged 

The impedance value should 
be logged once per minute on 
the minute. 

2.315 

24 

2 

EEAT52.2 

AirOK Fault, 
Read 

Impedance 
and Log 

If the Air OK fault occurs, the 
impedance should be read 
immediately (at the time of the 
fault) and logged to the file. 

2.315 

39 

3 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT53 

Alarm 

Priorities and 

Silencing 

Times 

Alarm priorities and silencing 
times table (Increment I) 

Pri Alarm Silence time 

1 Pump unplugged 
during manual mode 2 

2 Continuity fault 5 

3 Air lock detected 2 

4 Occlusion 2 

TBD Polling failure inf 

TBD Data log failure N/A 

11.693 

0 

4 

FEAT54 

Polling 

Request 

Failure 

Actions 

If a polling request fails, 

CARA should retry the request 
at one second intervals until 
successful for a maximum of 
three readings. 

2.105 

18 

3 

EEAT54.1 

Polling 

Request 

Failure 

Retries and 
Alarm 

If the maximum number of 
retry attempts is made with no 
success, CARA should issue 
an alarm and message stating 
that a data acquisition failure 
has occurred. 

1.754 

9 

4 

EEAT54.E1 

No 

Impedance in 
AC, 

Terminate AC 

If impedance reading cannot 
be obtained while in auto¬ 
control mode, CARA should 
exit auto-control mode 

3.157 

15 

5 

EEAT55 

Fog File 
Failure Alert 
Display 

If an attempt to write to the log 
file fails, CARA should 
display an alert message 
indicating that a data logging 
failure has occurred and 
continue operating. 

2.339 

9 

3 

EEAT56 

Pump Status 

Changes 

Timestamp 

When the pump status 
changes, an entry with a 
timestamp should be made to 
the log file to record the 
change in status. These log 
messages should correspond to 
the display message in req. 2. 
(This requirement is redundant 
in some cases) 

2.339 

0 

3 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT57 

Pump Startup 
condition 

A1 - Assume the pump is not 
in at startup (see Q62) and that 
the system will issue an 
interrupt when the status 
ehanges. 

4.677 

0 

2 

FEAT58 

Alarm Reset 
Availability 

A3 - Alarm reset buttons are 
available only when an alarm 
has been triggered (alarm 
buttons are soft buttons) - (see 
064) 

2.339 

0 

4 

EEAT59 

AirOK and 
Continuity 
Startup States 

A6 - Assume the oeelusion, 
Air-OK, and eontinuity status 
are OK when the pump is 
plugged in (see 062) and that 
the system will issue an 
interrupt when the status 
ehanges. 

4.677 

0 

2 

EEAT60 

Polling 

Request 

Interruption 

A15 - Polling requests and 
event service should not be 
interrupted. The event serviee 
will eomplete before other 
inputs are handled. (System 
interrupts will still oeeur, but 
input from them will be 
queued into the CARA) 

2.339 

9 

3 

EEAT61 

Flow Rate 

Caleulation 

Sequenee 

Alb - flow rate is ealeulated 
and displayed immediately 
when the pump is plugged in 
and the baek EMF value has 
been read 

7.016 

0 

3 

EEAT62 

Data Fogging 
Failure 
Additional 
Attempts 

A17 - If a data logging failure 
oeeurs, data logging attempts 
should eontinue as normal 

2.339 

0 

3 

EEAT63 

Pump 
Unplugged 
During Aetive 
Alarms 

A18 - If the pump unplugged 
during operation alarm is 
aetive and the alarm reset 
button is pressed, the alarm 
will be cleared and rest if the 
pump is still not present 
(system will return to initial 
state with no pump). 

2.339 

0 

4 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT64 

Polling 

Failure and 
Future 

Polling 

Attempts 

A19 - If a polling failure 
oeeurs, polling attempts will 
eontinue as normal 

2.339 

0 

3 

FEAT65 

Alarm Reset 
and Polling 
Deviee 
Interaetion 

A20 - If an alarm reset button 
is pressed and a polling deviee 
was the souree of an alarm, 
CARA will immediately poll 
the appropriate deviees in 
order by deviee or alarm 
priority. 

2.339 

0 

4 

EEAT66 

Logging 

Sequenee 

A21 - Fogging oeeurs as the 
last aetion in an event serviee 
generally. Alarms, however, 
are logged immediately when 
the alarm is issued if data 
logging is available. 

2.339 

0 

3 

EEAT67 

Alarm Silenee 
Disable 

Button 

A22 - If the alarm silenee 
button is pressed, the alarm 
silenee button will be disabled 
until a new audible alarm is 
aetive 

2.339 

0 

4 

EEAT68 

Multiple 
Alarm 
Conditions 
During an 
Alarm Silenee 

A23 - If the eurrent alarms are 
sileneed and a new alarm 
eondition oeeurs an audible 
alarm will be issued for the 
new alarm eondition. 

2.339 

0 

4 

EEAT69 

Polling 

Failure and 
Data Fogging 

A24 - If a polling failure 
oeeurs data logging will 
eontinue and note that the 
polled value is unknown 

2.339 

0 

3 

EEAT70 

Dialog Box 
Priority 

Only one dialog box ean be 
displayed at a time. If multiple 
dialog boxes are pending, the 
highest priority dialog will be 
displayed. 

1.169 

9 

2 

EEAT70.1 

Dialog Box 
Priority Order 

The dialog box priority is 
(from high to low) Terminate 
Auto-eontrol Souree Override 
Change Set Point 

1.169 

9 

2 
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FEAT Tag 

Name 

Requirement Text 

AHP 

Priority 

Rqts 

Clarity 

Safety 

FEAT70.2 

Dialog Box 
Priority 
Display 
Changes 

If a dialog box is eurrently 
displayed and the system 
eonditions ehange to require a 
higher priority dialog box to 
be displayed, the original 
dialog box will be elosed and 
the higher priority dialog will 
be displayed. 

1.169 

9 

2 

FEAT70.2.1 

Dialog Box 
Re-Display 

When the higher priority 
dialog box is elosed, the lower 
priority dialog box will be re¬ 
displayed, unless Auto-eontrol 
is terminated. 

1.169 

9 

2 
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APPENDIX C: SEATOOLS CARA MODEL DESCRIPTIONS 


A. INTRODUCTION 

This appendix provides an overview of the SEATools model of the CARA 
Infusion Pump software [WRAIOla, b, c]. This model was designed based on the 
requirement set of the CARA listed in Appendix B. The interoperability between this 
model and requirement set provide the eonfirming evidenee for the dissertation 
hypothesis. 

B. VERSION 1 

Version 1 (actually vO.l in the SEATools directory) of the CARA model is a non¬ 
working, abstract view of the overall architecture implemented in version 2 (vO.2). Its 
only purpose is to give someone unfamiliar with the more detailed model in version 2 a 
high level overview of the major constructs in the model architecture. 

1. Parent Vertex: Puett Liang CARA 

The overall system environment consists of four main components: The Patient, 
the LSTAT stretcher, the Infusion Pump, and the CARA Software System (see Eigure 100 
below). Eater in version 2, the patient is removed from the model and the infusion pump 
and ESTAT are modeled as external simulations. The major system flows in this vertex 
includes the following: fluid from the pump to the patient, blood pressures {bps) from the 
patient to the ESTAT (which then passes them on to the CARA), inputs from CARA to 
the ESTAT and pump {LSTAT_commands and pump_commands), and finally sensor 
readings from the ESTAT and pump to CARA {LSTAT_status and 
pump_sensor_readings). 
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0 ms 



Figure 100 Top Level CARA Model vl 


2, Parent Vertex: CARA 

This level of version 1 shows the three main modules of the design: a 
Pump Control_Module with a main function of resolving the blood pressure to use and 
determining the appropriate flow rate for the pump, an lO Module with a main function 
of sending and receiving inputs to the CARA operator via the display, and the 
Management_Module with main functions of monitoring the status of the pump, the lines, 
and the system and for logging data into the resuscitation file (see Figure 101 below). 


0 ms 



Figure 101 CARA Software Model vl 
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3, Parent Vertex: Management Module 

Central to this module is a manual_mode_interlock that is the primary operator 
responsible for returning the system to a manual mode in ease of failure of any 
component. Feeding this operator is data from the linejnonitor that monitors the sensor 
readings from the pump and LSTAT. Also feeding the manual_mode_interlock is a 
processor watchdog. This watchdog would be implemented on a separate processor 
from the main processor handling the bulk of the operations and is responsible for 
sensing any major processor failure and then alerting the operator (via the display). One 
final element of the Management_Module is the Resuscitation_File where all information 
about the changing state of the CARA system is recorded (see Figure 102 below). 



Figure 102 Management Module vl 
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4, Parent Vertex: Pump Control Module 

This is the major safety critical module of the CARA. It is responsible for 
resolving what blood pressure to use and for determining the correct input to the pump 
when the system is in auto-control mode (see Figure 103 below). Because of the safety 
critical nature of this module, we chose to implement this with Triple Modular 
Redundancy (TMR). This specific safety architecture was not called for explicitly in the 
requirement statement; however, the safety environment implicitly requires some form of 
redundancy to ensure that the proper commands are sent to the pump. The TMR 
architecture uses three concurrent modules performing similar functions and producing 
similar output, but using different internal algorithms in their calculations. A voting 
element is then responsible for determining which output to use. 



Figure 103 Pump Control Module vl 
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5, Parent Vertex: lO Module 

This module handles the input and output to the CARA display for the benefit of 
the CARA operator (see Figure 104 below). The alarm functions have been separated 
from other display functions to help isolate the safety critical functions. Also note the 
duplicate alarm_controllerl and 2. This additional alarm_controller would be 
implemented on the second processor with the processor watchdog so that in case of 
processor failure, alarms would be raised to the display. 



Figure 104 lO Module vl 


B. VERSION 2 

Version 2 (actually vO.2 within SEATools) is the working prototype that 
implements a majority of the CARA requirements specified in Segment 3 of the CARA 
Requirement Statement [WRAIOlc]. This version is much more detailed than version 1 
and is described in many more layers of decomposition. The "human" element (the 
patient and CARA operator) has been removed from the model in this version. The 
external interfaces to the system are modeled as simulators for the LSTAT, the Infusion 
Pump, and the CARA Display. 
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1, Parent Vertex: Puett Liang CARA 

The overall system environment consists of just three main components: the 
LSTAT stretcher is assumed to provide the majority of patient related information (e.g. 
blood pressures), the Infusion_Pump is the main item for control, and the CARA Software 
System is the system driving the infusion pump based on data received from the LSTAT 
(see Figure 105 below). The major system flows in this vertex between the CARA and 
LSTAT are the following: three different kinds of blood pressures {aline_bp, 
pulsejwavejbp, cuff_bp), additional sensor data from the LSTAT (a signal that the 
LSTAT is turned on {LSTAT_power_on) and the status of the pump 
(pump_plugged_in_status)), and an output from CARA to the LSTAT (commands to 
inflate the blood pressure cuff (inflate_cuff)). The major system flows between the 
CARA and the Infusion Pump are the following: the pump speed to the pump (a 
voltage), from the pump several safety related data items (impedance, 
continuity disrupted, occlusion_detected, and air_disrupted), and from the pump the 
back_EMF which is proportional to the actual rate at which the pump in infusing liquid. 


0 ms 



Figure 105 CARA Software Model v2 
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2, Parent Vertex: Infusion Pump 

This level shows the deeomposition of the Infusion Pump. There is an eight pin 
ribbon cable between the pump and CARA. Eight of the terminators in this level 
correspond to the pins of the ribbon cable — only 5 of which actually interact with CARA 
(pin3 jyumpspeedvoltage, pin4_back_EMF, pinSAirOK, pin7_OccOK, and 
pin8_impedance_signaf) (see Figure 106). The requirements also describe the need for 
continuity checking of all the pins via a hardware interlock — this is modeled as an 
additional terminator {continuity_interlock). 
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Figure 106 Infusion Pump Pin-outs v2 
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3, Parent Vertex: CARA 

This level shows the three main modules of the design; a Pump_Control_Module 
with a main function of resolving the blood pressure to use and determining the 
appropriate flow rate for the pump, an IO_Module with a main function of sending and 
receiving inputs to the CARA operator via the display, and the Management_Module 
with main functions of monitoring the status of the pump, the lines, and the system and 
for logging data into the historical resuscitation file (see Figure 107). 



Figure 107 CARA System Modules v2 
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4, Parent Vertex: Management Module 

Central to this module is a manual_mode_interlock that is the primary operator 
responsible for returning the system to a manual mode in case of failure of any 
component (see Figure 108). Feeding this operator is data from the line monitor that 
monitors the sensor readings from the pump and LSTAT. Also feeding the 
manualjnodejnterlock is a processor watchdog. This watchdog would be implemented 
on a separate processor from the main processor handling the bulk of the operations and 
is responsible for sensing any major processor failure and then alerting the operator (via 
the display). One final element of the Management_Module is the resuscitationJile 
where all information about the changing state of the CARA system is recorded. 



Figure 108 Management Module v2 
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5, Parent Vertex: Pump Control Module 

This is the major safety critical module of the CARA. It is responsible for 
resolving what blood pressure to use and for determining the correct input to the pump 
when the system is in auto-control mode. Because of the safety critical nature of this 
module, we chose to implement this with Triple Modular Redundancy (TMR) (see Figure 
109). This specific safety architecture was not called for explicitly in the requirement 
statement; however, the safety environment implicitly requires some form of redundancy 
to ensure that the proper commands are sent to the pump. The TMR architecture uses 
three concurrent modules performing similar functions and producing similar output, but 
using different internal algorithms in their calculations. A voting element is then 
responsible for determining which output to use. Modulel is the only module of the three 
that has been fully decomposed. Modules! & 3 could be decomposed similarly to 
Modulel but would use different algorithms (inserted at the programming stage). 



Figure 109 Pump Control Module v2 
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6, Parent Vertex: lO Module 

This module handles the input and output to the CARA display for the benefit of 
the CARA operator. Note that unlike version 1 (Figure 101), in this version the CARA 
display has been modeled as a decomposable terminator within this module (see Figure 
110). The alarm functions have been separated from other display functions to help 
isolate the safety critical functions. Also note the duplicate alarm_controUer 1. This 
additional alarm_controller would be implemented on the second processor with the 
processorjwatchdog so that in case of processor failure, alarms would be raised to the 
display. 


0 ms 
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7, Parent Vertex: Line Monitor 

This module (inside the Management_Module) handles and monitors the sensor 
readings eoming from the pump (see Figure 111). In case of any problem readings, a 
lineJault is generated which is immediately sent to the manualjnodejnterlock (see 
Figure 108). Determining the proper value of impedance, air_disrupted, and back_EMF 
readings requires further decomposition of these operators. 
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Figure 111 Line Monitor v2 
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8, Parent Vertex: Resuscitation File 

This module consists of a series of operators that accept data of a particular type 
and convert it into data Jor Jile format. The resuscitation Jile itself is modeled as a 
looping data stream created by the Resuscitation Jile_Generator where new additional 
entries are appended onto the end of the fde (see Figure 112 below). 



Figure 112 Resuscitation File v2 
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9, Parent Vertex: Modulel 

This parent operator is deeomposed into two main funetions; first, a blood 
pressure ealeulator {BP_calculator) responsible for determining which blood pressure to 
use during further calculations, and second, a Pump Speed Calculator which determines 
the appropriate pump command to issue (see Figure 113). Recall that there are two other 
concurrent modules {Module! & 3) (Figure 109) that are performing similar tasks but are 
utilizing different computing algorithms. 



Figure 113 Modulel v2 
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10. Parent Vertex: Voting Element 

This operator is decomposed into two main sub-operators (see Figure 114). First, 
the Vote operator compares the inputs from Module 1, 2, 3. If the all the data are with a 
set tolerance of each other, the operator averages the values and outputs the realjbp (for 
the display and the resuscitation Jile) and the pump speed. If two of the inputs are 
within tolerance and one is outside tolerance, it disregards the value outside tolerance, 
averages the other two and outputs the average. If all three values are outside tolerance, 
the Vote operator disregards all three values and waits for satisfactory data. The 
Terminate_Autocontrol operator is responsible for returning the system to manual control 
if the manual mode interlock command is invoked. 



Figure 114 Voting Element v2 
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11. Parent Vertex: Alarm Controllerl 

This operator accepts alarm generating data streams and outputs alarm data (both 
text and audio alarm) to the CARA display(see Figure 115 below). A second controller 
{alarm_controiler2 recall Figure 104) is implemented on the second processor to enable 
alarm data to be transmitted to the display in the case of processor failure. 



Figure 115 Alarm Controllerl v2 
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12. Parent Vertex: Display Driver 

This module contains a series of operators that act as drivers for the information 
displayed on the CARA display (see Figure 116). Some of these operators (the graph 
operators in particular) maintain aggregate data to send to the display. Also several of the 
operators function by comparing any new data to old data and only update the display in 
the case of changes. 
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Figure 116 Display Driver v2 
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13. Parent Vertex: Display 

This module is a decomposed terminator that simulates the functions of the 
CARA Display. Each terminator represents separate sets of data that can be displayed on 
the Display (see Figure 117). This module also simulates user input in the way of 
operator_commands (button pushes) from the Display. 
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Figure 117 Display v2 
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14, Parent Vertex: AirOK Monitor 

This operator is decomposed in order to allow a timer to function. If the 
Start_Air_Timer receives input that there is air disruption, then it waits the allotted time 
to see if air becomes OK. If it does not, then the Generate_Air Jault fires indicating a 
line^ault. If the Start_Air_Timer does receive good data, then the timer is reset and the 
fault generator does not fire (see Figure 118 below). 
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Figure 118 AirOK Monitor v2 
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15. Parent Vertex: EMF calculator 

Two major functions are modeled in this module (see Figure 119). First, EMF 
polling {Start_EMF_Poiling) takes place so that appropriate back_EMF values can be 
accumulated to calculate both the infuse rate and the total volume infused 
{Calculate_Infused_Volume). These values are later sent to the display and the 
resuscitation Jile (recall Figure 108 and Figure 111). Secondly, if the back_EMF \sl\uqs 
are unaeceptable (absent or out of tolerance), the module waits the appropriate time for 
acceptable data and then generates a line J'ault that eventually sets the system back into 
manual mode. 
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Figure 119 FMF Calculator v2 
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16, Parent Vertex: Impedance Monitor 

Much like the EMF_Calculator, two major funetions are modeled in this module 
(see Figure 120). First, impedance polling takes place {Start_Impedance Polling) so that 
appropriate impedance values can be accumulated to send to the resuscitationJile. 
Secondly, if the impedance values are unacceptable (absent or out of tolerance — 
Low_or_No_Impedance), the module waits the appropriate time for acceptable data and 
then generates a line^ault that eventually sets the system baek into manual mode. 
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Figure 120 Impedance Monitor v2 
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17. Parent Vertex: BP Calculator 

This operator has been decomposed into three operators; first, the 
Aline Corroborator which attempts to generate a corroborated arterial line blood 
pressure for future calculation; second, the Pulse_Wave_Corroborator which attempts to 
generate a corroborated pulse wave blood pressure for future calculation; and finally, a 
BP Priority Calculator which given the blood pressures available (arterial line, pulse 
wave, and cuff) generates the blood pressure that will be used {corroborated bp 1) based 
on a blood pressure priority scheme (see Figure 121). 



Figure 121 BP Calculator v2 
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